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/>
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
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--
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