Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

DJB about NSEC3

21 views
Skip to first unread message

Roy Arends

unread,
Sep 2, 2008, 4:50:15 AM9/2/08
to
DJB writes:

DNSSEC reduces existing confidentiality by publishing the complete list of
"secured" DNS records. This publication is integrated into the DNSSEC
protocol; it is independent of classic "zone transfers" and cannot be
disabled by administrators. The "NSEC3" variant of DNSSEC attempts to
reduce this exposure but is almost always breakable.

(source: http://dnscurve.org/dnssec.html retrieved Tuesday, september
2nd, 9:31 am BST)

I'd like to have more information how the "NSEC3" variant of DNSSEC is
almost always breakable? I'd like to know how to interpret "almost always
breakable".

Thanks,

Roy Arends
Nominet

--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

bert hubert

unread,
Sep 2, 2008, 5:42:35 AM9/2/08
to
On Tue, Sep 02, 2008 at 09:50:15AM +0100, Roy Arends wrote:
> I'd like to have more information how the "NSEC3" variant of DNSSEC is
> almost always breakable? I'd like to know how to interpret "almost always
> breakable".

I think it has been established that NSEC(3) allows the creation of
non-existent names within secured zones, if I followed things directly.

So even if importantbank.com is signed, I can try to spoof in
NS records for secure.importantbank.com, using a purloined NSEC(3) record that
covers secure.importantbank.com. The secure.importantbank.com zone is then
unsigned, and contains the data of my choice.

As long as secure.importantbank.com does not exist already of course.

As a precautionary measure, importantbank.com might want to have dummy
records for everything that 'looks' official.

Bert

--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services

Olaf Kolkman

unread,
Sep 2, 2008, 6:34:11 AM9/2/08
to
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-4--621200939
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit


On Sep 2, 2008, at 11:42 AM, bert hubert wrote:

> On Tue, Sep 02, 2008 at 09:50:15AM +0100, Roy Arends wrote:
>> I'd like to have more information how the "NSEC3" variant of DNSSEC
>> is
>> almost always breakable? I'd like to know how to interpret "almost
>> always
>> breakable".
>
> I think it has been established that NSEC(3) allows the creation of
> non-existent names within secured zones, if I followed things
> directly.
>
> So even if importantbank.com is signed, I can try to spoof in
> NS records for secure.importantbank.com, using a purloined NSEC(3)
> record that
> covers secure.importantbank.com. The secure.importantbank.com zone
> is then
> unsigned, and contains the data of my choice.
>
> As long as secure.importantbank.com does not exist already of course.
>
> As a precautionary measure, importantbank.com might want to have dummy
> records for everything that 'looks' official.


How would that work provided that:

- .com deploys NSEC3 with opt-out
- There is a secure delegation from .com to importantbank.com
- And importantbank.com does not deploy OPT-OUT but contains a full
NSEC3 chain?

On the latter assumption please note that the OPT-OUT bit is only
supposed to be set over name-spans that only contain delegations and
has been designed specifically 'delegation-centric' zones such as
TLDs. If importantbank.com would be using opt-out they could be
subject to the attack you describe but they would be shooting
themselves in the feet.

I would think that the warnings in 5011 are big enough: opt-out is
under adult supervision only (TLDs are often parents... pun intended)

--Olaf

--Apple-Mail-4--621200939
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: This message is locally signed.

iEYEARECAAYFAki9FqMACgkQtN/ca3YJIocA4ACg1WPg73lMx413nfotrt7La7pT
Y9MAnA9wytRmbHU9bhCKIN344GX/utwG
=E3F7
-----END PGP SIGNATURE-----

--Apple-Mail-4--621200939--

Mark Andrews

unread,
Sep 2, 2008, 7:20:26 AM9/2/08
to

> On Tue, Sep 02, 2008 at 09:50:15AM +0100, Roy Arends wrote:
> > I'd like to have more information how the "NSEC3" variant of DNSSEC is
> > almost always breakable? I'd like to know how to interpret "almost always
> > breakable".
>
> I think it has been established that NSEC(3) allows the creation of
> non-existent names within secured zones, if I followed things directly.
>
> So even if importantbank.com is signed, I can try to spoof in
> NS records for secure.importantbank.com, using a purloined NSEC(3) record tha
> t
> covers secure.importantbank.com. The secure.importantbank.com zone is then
> unsigned, and contains the data of my choice.
>
> As long as secure.importantbank.com does not exist already of course.
>
> As a precautionary measure, importantbank.com might want to have dummy
> records for everything that 'looks' official.
>
> Bert

Assuming the optout is not in use.

You can't bring a secure delegation into existance under a
NSEC3 zone and have the subzone validate. NSEC3 is as
strong as NSEC for this case.

You can bring a insecure delegation into existance iff there
is another insecure delegation and the hash of the name
your are trying to bring into existance matches the hash
of a existing insecure delegation.

Given the it's a sha1 hash that's n in 2^160 for the hash
of any abitrary name matching one a existing nsec3 hash where
n is the number of insecure delegations.

For all practical purposes this is impossible.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org

Mark Andrews

unread,
Sep 2, 2008, 7:23:59 AM9/2/08
to

All importantbank.com has to do is not have insecure delegations.

0 new messages