Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On 2/23/2010 1:40 PM, Paul Wouters wrote: > 4641bis is "DNSSEC Operational Practices". Why add something and then > immediatley say "SHOULD NOT be a factor"? You snipped the bit that answered this question. The fact that very smart people who know the protocol well even took time to discuss the issue is (in my mind) a clear indication that the topic is worth mentioning in a document that describes "DNSSEC Operational Practices." By explicitly mentioning the issue, providing a clear statement that it should not be a factor, and a reference to the details of why, we provide a service to all of the people who do not know the subject matter as well as we do who run the risk of being taken in by FUD. Please keep in mind who the target audience is. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Tue, 23 Feb 2010, Doug Barton wrote: Because NSEC3 uses a hash function there is an unimaginably small chance that two different hostnames could produce the same hash output, and and even smaller chance that such a collision could be exploitable by an attacker. This issue SHOULD NOT be a factor in making an operational decision about which type of signing to use. See [RFC5155] for more information, including the relevant mathematical background. 4641bis is "DNSSEC Operational Practices". Why add something and then immediatley say "SHOULD NOT be a factor"? This is not Matlock :) Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On 02/23/10 07:42, Paul Wouters wrote: > On Mon, 22 Feb 2010, Doug Barton wrote: > >> My thoughts are sort of leaning in the direction that a very brief >> mention of the issue combined with a reference to what Evan quoted in >> 5155 (which seems to handle the issue well) is probably the right >> direction to go. > > I"m with Andrew and people. Mentioning it in 4146bis gives is much > more weight then it deserved, and I think will cause people to > perhaps make the wrong decision. "Wrong" according to who? Leaving aside my deep concerns about the thinking that went into that statement, I think the fact that this thread exists at all indicates that there is a serious FUD potential here that 4641bis should address. I suggest a statement like the following (very rough): Because NSEC3 uses a hash function there is an unimaginably small chance that two different hostnames could produce the same hash output, and and even smaller chance that such a collision could be exploitable by an attacker. This issue SHOULD NOT be a factor in making an operational decision about which type of signing to use. See [RFC5155] for more information, including the relevant mathematical background. hth, Doug (We report, YOU decide) -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Feb 23, 2010, at 10:40 AM, Paul Wouters wrote: > On Mon, 22 Feb 2010, Doug Barton wrote: > >> On 02/22/10 05:14, Roy Arends wrote: >>> On Feb 22, 2010, at 4:44 AM, W.C.A. Wijngaards wrote: The deployment of NSEC3-signed toplevel domains is a giant hash collision test of typo dictionaries. >>> >>> Not really, most (will) use Opt-Out. >> >> Has anyone done a side-by-side comparison of nsec/nsec3 +/- opt-out with >> the benefits and drawbacks of each? If such a document already exists >> and I've just missed it my apologies. > > Not that I know of, but for a TLD of 1.2M entries, we decided to use > NSEC3 without optout. To the signer machine, there is not that much > difference, especially when you take in signature re-use. So apart > from the 10M+ zones, I don't really see the use of optout much. Unless > your nameservers are old 32bit hardware and stuck with 3GB per bind process. Hi Doug, We (Nominet UK) operate on a register of over 8M names, distributed over several second level domains, of which co.uk is by far the largest. For us, NSEC3 is the default. We decided to stay away from NSEC on all delegation centric zones we operate, including the UK top level domain. Staying away from NSEC will keep our zones lightweight and flexible, considering we dynamically update them by the minute. Due to OptOut, the resulting DNSSEC overhead in terms of size, incremental zone transfers, occasional full zone transfers, memory footprint, CPU usage, etc, are negligible. I don't really see the benefit of using NSEC. Too much redundant crypto and name leakage in NSEC in light of no real benefits. Kind Regards Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Feb 23, 2010, at 2:03 PM, Evan Hunt wrote: >>> hashes. However, NSEC records are sometimes returned in response to >>> DO=0 queries, >> >> Wouldn't that be an implementation bug? > > Not if it was an ANY query. Otherwise, yes. Or an NSEC query. Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
> >hashes. However, NSEC records are sometimes returned in response to > >DO=0 queries, > > Wouldn't that be an implementation bug? Not if it was an ANY query. Otherwise, yes. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Tue, 23 Feb 2010, Nicholas Weaver wrote: On Feb 23, 2010, at 6:26 AM, Todd Glassey wrote: Sorry folks - but disclosure is the rule - so something about the potential hash collision needs to be in the document and there are liability issues for the people and their sponsor's involved who vote to keep these types of key factor's out of the work products because they dont want their documents soiled by 'statements that the lifetime of the Intellectual Property is limited' which is what putting anything about why the thing may not work does IMHO. SHA1 is 160B output size. Do you really expect zones with 2^80 entries in them (the point when the birthday paradox limit start mattering)? One in a septillion probabilities on human-scale items is zero for any reasonable value of zero. There is no liability here. The point here is that this is discussed on RFC5155 (or even 3174). 4641bis is not meant to incorporate everything. It's goal is to provide a synopsis from our lengthy email discussions and previous RFCs, and provide a pointer to 5155 for a full discussion. 4641bis provides a summary of recommendations with the main considerations, not the ultimate list of theoretical end of the world possibilities. Throwing 'Intellectual Property' in this discussion is troll fodder. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Mon, 22 Feb 2010, Doug Barton wrote: My thoughts are sort of leaning in the direction that a very brief mention of the issue combined with a reference to what Evan quoted in 5155 (which seems to handle the issue well) is probably the right direction to go. I"m with Andrew and people. Mentioning it in 4146bis gives is much more weight then it deserved, and I think will cause people to perhaps make the wrong decision. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Mon, 22 Feb 2010, Doug Barton wrote: On 02/22/10 05:14, Roy Arends wrote: On Feb 22, 2010, at 4:44 AM, W.C.A. Wijngaards wrote: The deployment of NSEC3-signed toplevel domains is a giant hash collision test of typo dictionaries. Not really, most (will) use Opt-Out. Has anyone done a side-by-side comparison of nsec/nsec3 +/- opt-out with the benefits and drawbacks of each? If such a document already exists and I've just missed it my apologies. Not that I know of, but for a TLD of 1.2M entries, we decided to use NSEC3 without optout. To the signer machine, there is not that much difference, especially when you take in signature re-use. So apart from the 10M+ zones, I don't really see the use of optout much. Unless your nameservers are old 32bit hardware and stuck with 3GB per bind process. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Feb 23, 2010, at 6:26 AM, Todd Glassey wrote: > Sorry folks - but disclosure is the rule - so something about the potential > hash collision needs to be in the document and there are liability issues for > the people and their sponsor's involved who vote to keep these types of key > factor's out of the work products because they dont want their documents > soiled by 'statements that the lifetime of the Intellectual Property is > limited' which is what putting anything about why the thing may not work does > IMHO. SHA1 is 160B output size. Do you really expect zones with 2^80 entries in them (the point when the birthday paradox limit start mattering)? One in a septillion probabilities on human-scale items is zero for any reasonable value of zero. There is no liability here. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Tue, 23 Feb 2010, Florian Weimer wrote: hashes. However, NSEC records are sometimes returned in response to DO=0 queries, Wouldn't that be an implementation bug? Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On 2/22/2010 8:46 PM, Doug Barton wrote: On 02/22/10 11:59, Evan Hunt wrote: Note that RFC 5155 takes the time to put the issue to rest not once but twice: I am on the fence regarding the necessity of mentioning the hash collision issue in 4641bis. While other potential security concerns are not directly relevant to the topic, this one is (in spite of the fact that the possibility of a useful collision is unimaginably small). My thoughts are sort of leaning in the direction that a very brief mention of the issue combined with a reference to what Evan quoted in 5155 (which seems to handle the issue well) is probably the right direction to go. Doug the real issue here is that there is no standard - and any IETF initiative may or may not include content like this meaning its up to the WG as to whether they produce documents that are uniform or documents which make it harder to rely on IETF standards. Why this is important is consistency - something the IETF has very little of except in its massively uncoordinated number of voices all screaming they dont and wont be accountable for the damage their actions cause. Sorry folks - but disclosure is the rule - so something about the potential hash collision needs to be in the document and there are liability issues for the people and their sponsor's involved who vote to keep these types of key factor's out of the work products because they dont want their documents soiled by 'statements that the lifetime of the Intellectual Property is limited' which is what putting anything about why the thing may not work does IMHO. Todd Glassey Doug No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.435 / Virus Database: 271.1.1/2704 - Release Date: 02/22/10 19:34:00 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Feb 23, 2010, at 8:20 AM, Florian Weimer wrote: > * Olaf Kolkman: > >> 5.3.3. NSEC3 Salt >> >> The salt with NSEC3 is not used to increase the work required by an >> attacker attacking multiple domains, but as a method to enable >> creating a new set of hash values if at some point that might be >> required. The salt is used as a "roll over". The FQDN RRlabel, >> which is part of the value that is hashed, already ensures that brute >> force work for one RRlabel can not be re-used to attack other RRlabel >> due to their uniquenes. >> >> Key rollovers limit the amount of time attackers can spend on >> attacking a certain key before it is retired. The salt serves the >> same purpose for the hashes, which are independant of the key being >> >> >> >> Kolkman & GiebenExpires September 8, 2009 [Page 33] >> Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 >> >> >> used, and therefor do not change when rolling over a key. Changing >> the salt would cause an attacker to lose all precalculated work for >> that zone. >> >> The salt of all NSEC3 records in a zone needs to be the same. Since >> changing the salt requires the NSEC3 records to be regenerated, and >> thus requires generating new RRSIG's over these NSEC3 records, it is >> recommended to only change the salt when changing the Zone Signing >> Key, as that process in itself already requires all RRSIG's to be >> regenerated. > > "However, unlike Zone Signing Key changes, NSEC3 salt changes do not > need special rollover procedures. It is possible to change the salt > each time the zone is updated." > ACK > (Assuming that this is true, which I think it is.) > > Perhaps the following is helpful as well? > > 5.3.5 Response size considerations > > NSEC3 records are larger than NSEC records because of the embedded > hashes. However, NSEC records are sometimes returned in response to > DO=0 queries, pushing the response over the 512 byte limit and causing > TCP fallback (or worse). This does not happen with NSEC3 records > because their owner name does not normally match the queried name. > Therefore, NSEC3 records provide better insulation of child zones from > the DNSSEC deployment in the parent zone. Isn't that only the case for QTYPE=ANY? Or when the server at the authoritative side is broken? For both cases I do not think that this is a strong consideration. Also, but orthogonal, At Labs we are about to measure the impact of the amount of NSEC3 iterations on a recursive nameserver. Maybe there are some additional considerations that flow from that, will keep you all posted. --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
* Roy Arends: > So, a collision (that is nothing more than a collision) is a problem > for NSEC3, but not for RSASHA1? You still need a collision over somewhat structured data. Chosen-prefix collisions (with different prefixes) are likely not *that* far away after that, and those break RSASHA1 completely (in the sense that you can register a crafted org domain name and get an RRSIG from org that fits example.org as well, with private key material known to you). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
* Olaf Kolkman: > 5.3.3. NSEC3 Salt > >The salt with NSEC3 is not used to increase the work required by an >attacker attacking multiple domains, but as a method to enable >creating a new set of hash values if at some point that might be >required. The salt is used as a "roll over". The FQDN RRlabel, >which is part of the value that is hashed, already ensures that brute >force work for one RRlabel can not be re-used to attack other RRlabel >due to their uniquenes. > >Key rollovers limit the amount of time attackers can spend on >attacking a certain key before it is retired. The salt serves the >same purpose for the hashes, which are independant of the key being > > > > Kolkman & GiebenExpires September 8, 2009 [Page 33] > Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 > > >used, and therefor do not change when rolling over a key. Changing >the salt would cause an attacker to lose all precalculated work for >that zone. > >The salt of all NSEC3 records in a zone needs to be the same. Since >changing the salt requires the NSEC3 records to be regenerated, and >thus requires generating new RRSIG's over these NSEC3 records, it is >recommended to only change the salt when changing the Zone Signing >Key, as that process in itself already requires all RRSIG's to be >regenerated. "However, unlike Zone Signing Key changes, NSEC3 salt changes do not need special rollover procedures. It is possible to change the salt each time the zone is updated." (Assuming that this is true, which I think it is.) Perhaps the following is helpful as well? 5.3.5 Response size considerations NSEC3 records are larger than NSEC records because of the embedded hashes. However, NSEC records are sometimes returned in response to DO=0 queries, pushing the response over the 512 byte limit and causing TCP fallback (or worse). This does not happen with NSEC3 records because their owner name does not normally match the queried name. Therefore, NSEC3 records provide better insulation of child zones from the DNSSEC deployment in the parent zone. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On 02/22/10 05:14, Roy Arends wrote: > On Feb 22, 2010, at 4:44 AM, W.C.A. Wijngaards wrote: >> The deployment of NSEC3-signed toplevel domains is a giant hash >> collision test of typo dictionaries. > > Not really, most (will) use Opt-Out. Has anyone done a side-by-side comparison of nsec/nsec3 +/- opt-out with the benefits and drawbacks of each? If such a document already exists and I've just missed it my apologies. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On 02/22/10 11:59, Evan Hunt wrote: > Note that RFC 5155 takes the time to put the issue to rest not once but > twice: I am on the fence regarding the necessity of mentioning the hash collision issue in 4641bis. While other potential security concerns are not directly relevant to the topic, this one is (in spite of the fact that the possibility of a useful collision is unimaginably small). My thoughts are sort of leaning in the direction that a very brief mention of the issue combined with a reference to what Evan quoted in 5155 (which seems to handle the issue well) is probably the right direction to go. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
--On 23 February 2010 11:06:50 +1100 Mark Andrews wrote: Drunk Sysadmins, Rouge Registrar, etc, etc. I'm sure that it will be a very large section. Apart from the slightly higher risk of software bugs because NSEC3 is more complicated. The other items have no impact of the decision to choose between NSEC and NSEC3 and as such are irrelevent. Oh I don't know. I think it could be argued NSEC3 is more likely to drive people to drink than NSEC ... :-) -- Alex Bligh ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
In message <222b7737-d294-4ef1-9f14-de4ca4c70...@dnss.ec>, Roy Arends writes: > On Feb 22, 2010, at 6:41 PM, Mark Andrews wrote: > > >=20 > >> The real problem is that a SHA1 hash collision would render all = > signatures wi > >> th RSASHA1 vulnerable. Haven't heard you about that.=20 > >=20 > > Hogwash. A collision is nothing more than a collision. See above. > > So, a collision (that is nothing more than a collision) is a problem for = > NSEC3, but not for RSASHA1? What matters is how the collision came about not that there is a collision. Just because something is extremely unlikely doesn't mean that it won't happen or that the process is broken. SHA1 being broken implies that collisions will happen more often. Seeing a collision doesn't imply that SHA1 is broken. > > For a zone with 30 million names the false positive rate is roughly > > 1 in 32^32/(3*10^7) (1/48716721244363430606789494423876100655197) > > queries. Around 40 9's. > > I agree, approximately, a probability of 1 in 2^135. > > >> I suggest that if you and Andrews want to have this claim rfc4641bis, = > you sho > >> uld not discriminate on NSEC3, but on everything that uses SHA1. > >>=20 > >>> (resign > >>> with a new salt, and also keep that 2-second update guarantee? - I = > would > >>> suggest some weasel words in agreements). > >>=20 > >> Nah, we love collisions, it makes it all so more efficient. > >>=20 > >> Besides, I think=20 > >> the probability of finding a bug in authoritative server software is = > way high > >> er than a hash-collision. > >=20 > > Indeed. But you would expect us to fix the bug once it was found. :-) > > I used to. Not anymore. > > See = > https://www.isc.org/community/blog/201002/surprise-bugs-and-release-schedu= > les > > Roy= -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Feb 22, 2010, at 7:06 PM, Mark Andrews wrote: > > In message , Roy Arends writes: >> This is absurd. If we're going to do this, I'd like the security consideratio >> ns to reflect all of the non-zero probabilities of errors occuring (those tha >> t have a higher probability). This includes software-bugs, hardware-bugs, pro >> bability of advances in factorization, randomness of PRNG for DNSKEYs, faulty >> calibration/low granularity of equipment measuring the transition between th >> e two hyperfine levels of the ground state of the caesium 133 atom. Gravitati >> onal Sphere of Influence of the 99942 Apophis on the Gravitational orbit of G >> PS satelites (Still having a higher probability than hash-collisions ;-)), Dr >> unk Sysadmins, Rouge Registrar, etc, etc. >> >> I'm sure that it will be a very large section. > > Apart from the slightly higher risk of software bugs because NSEC3 > is more complicated. The other items have no impact of the decision > to choose between NSEC and NSEC3 and as such are irrelevent. A slightly higher risk? Does a software bug probability of 1 count as a slightly higher risk? Note that the security considerations section in 4641-bis has a much wider scope than NSEC vs NSEC3. Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Feb 22, 2010, at 6:41 PM, Mark Andrews wrote: > >> The real problem is that a SHA1 hash collision would render all signatures wi >> th RSASHA1 vulnerable. Haven't heard you about that. > > Hogwash. A collision is nothing more than a collision. See above. So, a collision (that is nothing more than a collision) is a problem for NSEC3, but not for RSASHA1? > For a zone with 30 million names the false positive rate is roughly > 1 in 32^32/(3*10^7) (1/48716721244363430606789494423876100655197) > queries. Around 40 9's. I agree, approximately, a probability of 1 in 2^135. >> I suggest that if you and Andrews want to have this claim rfc4641bis, you sho >> uld not discriminate on NSEC3, but on everything that uses SHA1. >> >>> (resign >>> with a new salt, and also keep that 2-second update guarantee? - I would >>> suggest some weasel words in agreements). >> >> Nah, we love collisions, it makes it all so more efficient. >> >> Besides, I think >> the probability of finding a bug in authoritative server software is way high >> er than a hash-collision. > > Indeed. But you would expect us to fix the bug once it was found. :-) I used to. Not anymore. See https://www.isc.org/community/blog/201002/surprise-bugs-and-release-schedules Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On 2010-02-22, at 19:13, Mark Andrews wrote: The problem is that one is using a hash, not the strength of the hash. Precisely. See another remark in this thread about excluded middle and so on. -- Andrew Sullivan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Mon, Feb 22, 2010 at 4:24 PM, Mark Andrews wrote: > > In message , Eric > R > escorla writes: >> Well, IMO we shouldn't have addressed this in RFC 5155 either. It falls >> into the category of "basic assumptions" > > Basic assumptions should be noted. Should we also note the Heisenberg uncertainty principle? general relativity? The law of the excluded middle? -Ekr ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
In message , Eric R escorla writes: > Well, IMO we shouldn't have addressed this in RFC 5155 either. It falls > into the category of "basic assumptions" Basic assumptions should be noted. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
In message <20100222185157.go64...@shinkuro.com>, Andrew Sullivan writes: > On Mon, Feb 22, 2010 at 11:17:59AM -0500, Matt Larson wrote: > > > I am adamantly opposed to including > > any text about SHA1 hash collisions in an NSEC3 context. > > Add me to the choir. Actually, I'm opposed to including any text > about SHA-1 hash collisions in _any_ DNSSEC context until we write the > document, "Deprecating SHA-1 hash functions for DNSSEC". SHA256 and SHA512 have the same problem, just with different probabilities of collisions. The problem is that one is using a hash, not the strength of the hash. > A > > -- > Andrew Sullivan > a...@shinkuro.com > Shinkuro, Inc. > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
In message , Roy Arends writes: > On Feb 22, 2010, at 11:12 AM, Evan Hunt wrote: > > >> Using NSEC instead of NSEC3 because you fear SHA1 collisions does not > >> seem sensible, as if you fear SHA1 collisions, you have other more > >> significant problems with DNSSEC to worry about, and thus this is > >> not, in my opinion, reasonable. And it isn't sensible to suggest > >> users worry about it. If we are going to mention it, it should be > >> in security considerations, saying NSEC3 is dependent upon certain > >> properties of its hash algorithm (I forget now whether it is > >> collision resistance, pre-image resistance or or what), but this > >> should also point out the whole of DNSSEC is predicated on similar > >> qualities. > > > > +1 except for the "if". It is mathematically possible for collisions to > > occur with one approach and not the other, and it would be irresponsible > > not to make note of the fact, even if we agree that the chances of this > > occurring in nature are negligible. > > This is absurd. If we're going to do this, I'd like the security consideratio > ns to reflect all of the non-zero probabilities of errors occuring (those tha > t have a higher probability). This includes software-bugs, hardware-bugs, pro > bability of advances in factorization, randomness of PRNG for DNSKEYs, faulty > calibration/low granularity of equipment measuring the transition between th > e two hyperfine levels of the ground state of the caesium 133 atom. Gravitati > onal Sphere of Influence of the 99942 Apophis on the Gravitational orbit of G > PS satelites (Still having a higher probability than hash-collisions ;-)), Dr > unk Sysadmins, Rouge Registrar, etc, etc. > > I'm sure that it will be a very large section. Apart from the slightly higher risk of software bugs because NSEC3 is more complicated. The other items have no impact of the decision to choose between NSEC and NSEC3 and as such are irrelevent. > Roy > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
In message <699b9362-b927-4148-b79e-2aeb6d713...@dnss.ec>, Roy Arends writes: > On Feb 22, 2010, at 4:44 AM, W.C.A. Wijngaards wrote: > > > On 02/22/2010 04:53 AM, Roy Arends wrote: > >> On Feb 21, 2010, at 7:22 PM, Mark Andrews wrote: > >> > >>> NSEC3 > >>> has a non zero false positive rate due to the fact that the names > >>> are hashed. > >> > >> Are you going on again about the possibility of hash collisions is SHA-1? > > > > Yes. +1 for Marks point. > > > > The deployment of NSEC3-signed toplevel domains is a giant hash > > collision test of typo dictionaries. > > Not really, most (will) use Opt-Out. > > > What does the registry do when > > someone registers a new domain name that has a hash-collision > > We'll claim that sha-1 is broken, write a paper on it and have our 15 minutes > of fame. Meanwhile... Actually all you can claim is that you found a collision. It doesn't mean that sha-1 is broken. For sha-1 to be broken you need to be able to *manufacture* a collision or significantly reduce the cost of finding a collision. > In the real world, if someone registers the name 759345ihkjgrj345837458fjfgiu > sifghgvtsrhf8hfvihi.co.uk and its hash collides with example.co.uk (lets skip > the probability factor), than its just gotten a bit more efficient. One hash > matching 2 names, i.e. we can now deny two names for the price of one. As long as the collision falls into the correct set. For delegation only NSEC3 zones (single label) have three sets of NSEC3 hashes for owner names in the zone. The apex NSEC3, those that appear in the zone (secure delegations) and those that should not appear in the zone (opted out name). You don't want a delegation which collides with one of the other sets. > The real problem is that a SHA1 hash collision would render all signatures wi > th RSASHA1 vulnerable. Haven't heard you about that. Hogwash. A collision is nothing more than a collision. See above. There are roughly 63^37/32^32 (2575141059497371630) possible LDH names for every possible NSEC3 owner in a zones containing only single labels. The probability of any single query will collide is vanishing small. NSEC3 works because the number of hashed names in a zone is very very very much smaller than the size of the hash space and we are willing to accept a SERVFAIL on a collision for a name that is not in the zone but is in the namespace. For names that are in the zone we can ensure that there isn't a collision that matters. For a zone with 30 million names the false positive rate is roughly 1 in 32^32/(3*10^7) (1/48716721244363430606789494423876100655197) queries. Around 40 9's. > I suggest that if you and Andrews want to have this claim rfc4641bis, you sho > uld not discriminate on NSEC3, but on everything that uses SHA1. > > > (resign > > with a new salt, and also keep that 2-second update guarantee? - I would > > suggest some weasel words in agreements). > > Nah, we love collisions, it makes it all so more efficient. > > Besides, I think > the probability of finding a bug in authoritative server software is way high > er than a hash-collision. Indeed. But you would expect us to fix the bug once it was found. :-) > > But I agree more pertinent to choice is the increased CPU demand and > > larger packets when using NSEC3. And opt-out, obfuscation desiderata. > > All FUD. > > Roy > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On 22 feb 2010, at 17.17, Matt Larson wrote: > +1, total and complete agreement. I am adamantly opposed to including > any text about SHA1 hash collisions in an NSEC3 context. +1. jakob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Mon, Feb 22, 2010 at 11:59 AM, Evan Hunt wrote:
>> I have not seen anyone make a statement "NSEC3 is exactly as good as NSEC".
>>
>> I've seen the opposite by Mark Andrews:
>>
>> "Actually NSEC is technically better at proving non-existance."
>
> Mark was responding to an assertion to the contrary ("one is NOT better
> than the other") by making a boundary-condition quibble. I'm not sure
> whether he was arguing that the quibble should be noted in the draft
> or merely being pedantic, so I won't speak for him, but I personally
> think precision is a worthwhile goal here.
>
> Note that RFC 5155 takes the time to put the issue to rest not once but
> twice:
>
> Note that with the hash algorithm specified in this document,
> SHA-1, such collisions are highly unlikely.
>
> Hash collisions between QNAME and the owner name of an NSEC3 RR
> may occur. When they do, it will be impossible to prove the
> non- existence of the colliding QNAME. However, with SHA-1,
> this is highly unlikely (on the order of 1 in 2^160). Note that
> DNSSEC already relies on the presumption that a cryptographic
> hash function is second pre-image resistant, since these hash
> functions are used for generating and validating signatures and
> DS RRs.
>
> ... so I don't understand why 4641bis should not do so even once. (But
> this conversation has already taken more time than the probability of a
> random collision really merits, so whatever.)
Well, IMO we shouldn't have addressed this in RFC 5155 either. It falls
into the category of "basic assumptions"
-Ekr
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
> I have not seen anyone make a statement "NSEC3 is exactly as good as NSEC".
>
> I've seen the opposite by Mark Andrews:
>
> "Actually NSEC is technically better at proving non-existance."
Mark was responding to an assertion to the contrary ("one is NOT better
than the other") by making a boundary-condition quibble. I'm not sure
whether he was arguing that the quibble should be noted in the draft
or merely being pedantic, so I won't speak for him, but I personally
think precision is a worthwhile goal here.
Note that RFC 5155 takes the time to put the issue to rest not once but
twice:
Note that with the hash algorithm specified in this document,
SHA-1, such collisions are highly unlikely.
Hash collisions between QNAME and the owner name of an NSEC3 RR
may occur. When they do, it will be impossible to prove the
non- existence of the colliding QNAME. However, with SHA-1,
this is highly unlikely (on the order of 1 in 2^160). Note that
DNSSEC already relies on the presumption that a cryptographic
hash function is second pre-image resistant, since these hash
functions are used for generating and validating signatures and
DS RRs.
... so I don't understand why 4641bis should not do so even once. (But
this conversation has already taken more time than the probability of a
random collision really merits, so whatever.)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
--On 22 February 2010 09:05:47 -0800 Eric Rescorla wrote: On Mon, Feb 22, 2010 at 8:52 AM, Roy Arends wrote: On Feb 22, 2010, at 11:12 AM, Evan Hunt wrote: Alex Bligh wrote: Using NSEC instead of NSEC3 because you fear SHA1 collisions does not seem sensible ... And it isn't sensible to suggest users worry about it. If we are going to mention it, it should be in security considerations, saying NSEC3 is dependent upon certain properties of its hash algorithm (I forget now whether it is collision resistance, pre-image resistance or or what), but this should also point out the whole of DNSSEC is predicated on similar qualities. +1 except for the "if". It is mathematically possible for collisions to occur with one approach and not the other, and it would be irresponsible not to make note of the fact, even if we agree that the chances of this occurring in nature are negligible. This is absurd. If we're going to do this, I'd like the security considerations to reflect all of the non-zero probabilities of errors occuring ... Drunk Sysadmins, Rouge Registrar, etc, etc. I'm sure that it will be a very large section. Precisely. I realize it's hard to grasp precisely how small the statistical chances of a collision are, but they are just unbelievably small. Acting as if it is something that might actually happen just makes you look silly. I agree entirely. However, it does seem that there is a recurrent view that hash collisions are a risk worth discussing (hence this thread). My use of the words "if we are going to mention it" was more to quantify the probability of the problem that to say people should be worrying about it; if we don't quantify it, people seem to think it's worth worrying about, which I would suggest it is not. I am equally happy with a security considerations section that says in essence "if SHA-1 breaks then NSEC3 breaks, but then so does the rest of DNSSEC" as not mentioning it. What we shouldn't be doing is suggesting users should use this as a decision criterion between NSEC and NSEC3. There are plenty of reasons not to use NSEC3 (and to use it) way more signficant than the 10^-(large number) problem. I think it is much smaller than one in a trillion, by the way. I seem to remember it is smaller than one in (number of atoms in universe squared). -- Alex Bligh ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Mon, Feb 22, 2010 at 11:17:59AM -0500, Matt Larson wrote: > I am adamantly opposed to including > any text about SHA1 hash collisions in an NSEC3 context. Add me to the choir. Actually, I'm opposed to including any text about SHA-1 hash collisions in _any_ DNSSEC context until we write the document, "Deprecating SHA-1 hash functions for DNSSEC". A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Feb 22, 2010, at 12:23 PM, Evan Hunt wrote: >> This is absurd. If we're going to do this, I'd like the security >> considerations to reflect all of the non-zero probabilities of errors >> occuring (those that have a higher probability). > > My point is not to say that hash collisions are a problem or that NSEC3 is > a poor choice. My point is that it's bad form to make mathematically false > statements--even if they're *almost completely* true--and especially so > when you get anywhere near cryptographers. > > "NSEC3 is exactly as good as NSEC" is a mathematical statement. It's very, > very close to true, but in math that still makes it false. "NSEC3 is as > good as NSEC except under conditions so fantastically improbable that it's > safe to ignore them" is a few more words, but has the benefit of actually > being *true*, and I think that's what the draft should say. I have not seen anyone make a statement "NSEC3 is exactly as good as NSEC". I've seen the opposite by Mark Andrews: "Actually NSEC is technically better at proving non-existance." Which he bases on the possibility of hash-collisions without noting the 'fantastical improbability' of hash-collisions. If one considers hash-collisions probable enough to add it to a security section, it needs a discussion of the _impact_ of a hash-collision on proving (non-)existence (which I've demonstrated is negligible), but also discuss it in the presence of RSASHA1 signature algorithms. And I wasn't kidding in my last mail: If we are going to write that up in a security section, I think we need to consider more probable attack scenarios as well, don't you think? Otherwise, you'd have a section that is "very, very close to true, but in math that still makes it false.", especially so when you get anywhere near security-folk. Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Mon, Feb 22, 2010 at 9:23 AM, Evan Hunt wrote: >> This is absurd. If we're going to do this, I'd like the security >> considerations to reflect all of the non-zero probabilities of errors >> occuring (those that have a higher probability). > > I just answered this point in private mail to someone else, failing to > realize until after I'd sent it that it was off-list, so I'll repeat > myself... > > My point is not to say that hash collisions are a problem or that NSEC3 is > a poor choice. My point is that it's bad form to make mathematically false > statements--even if they're *almost completely* true--and especially so > when you get anywhere near cryptographers. > > "NSEC3 is exactly as good as NSEC" is a mathematical statement. It's very, > very close to true, but in math that still makes it false. "NSEC3 is as > good as NSEC except under conditions so fantastically improbable that it's > safe to ignore them" is a few more words, but has the benefit of actually > being *true*, and I think that's what the draft should say. Well, I wouldn't want to say "NSEC3 is exactly as good as NSEC" in any case, since it's not true. It's more inconvenient to implement, and somewhat more secure. So, I agree that we shouldn't say things that are factually false, but I'm not overly concerned about this. -Ekr ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
--- SNIP --- Precisely. I realize it's hard to grasp precisely how small the statistical chances of a collision are, but they are just unbelievably small. Acting as if it is something that might actually happen just makes you look silly. Actually Erik ... the problem isn't the statistical likelihood of an accidental collision - its the potential for an engineered one and one in a trillion is too many possible problems. Todd Glassey -Ekr ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.435 / Virus Database: 271.1.1/2703 - Release Date: 02/22/10 07:34:00 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
> This is absurd. If we're going to do this, I'd like the security > considerations to reflect all of the non-zero probabilities of errors > occuring (those that have a higher probability). I just answered this point in private mail to someone else, failing to realize until after I'd sent it that it was off-list, so I'll repeat myself... My point is not to say that hash collisions are a problem or that NSEC3 is a poor choice. My point is that it's bad form to make mathematically false statements--even if they're *almost completely* true--and especially so when you get anywhere near cryptographers. "NSEC3 is exactly as good as NSEC" is a mathematical statement. It's very, very close to true, but in math that still makes it false. "NSEC3 is as good as NSEC except under conditions so fantastically improbable that it's safe to ignore them" is a few more words, but has the benefit of actually being *true*, and I think that's what the draft should say. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Mon, Feb 22, 2010 at 8:52 AM, Roy Arends wrote: > On Feb 22, 2010, at 11:12 AM, Evan Hunt wrote: > >>> Using NSEC instead of NSEC3 because you fear SHA1 collisions does not >>> seem sensible, as if you fear SHA1 collisions, you have other more >>> significant problems with DNSSEC to worry about, and thus this is >>> not, in my opinion, reasonable. And it isn't sensible to suggest >>> users worry about it. If we are going to mention it, it should be >>> in security considerations, saying NSEC3 is dependent upon certain >>> properties of its hash algorithm (I forget now whether it is >>> collision resistance, pre-image resistance or or what), but this >>> should also point out the whole of DNSSEC is predicated on similar >>> qualities. >> >> +1 except for the "if". It is mathematically possible for collisions to >> occur with one approach and not the other, and it would be irresponsible >> not to make note of the fact, even if we agree that the chances of this >> occurring in nature are negligible. > > This is absurd. If we're going to do this, I'd like the security > considerations to reflect all of the non-zero probabilities of errors > occuring (those that have a higher probability). This includes software-bugs, > hardware-bugs, probability of advances in factorization, randomness of PRNG > for DNSKEYs, faulty calibration/low granularity of equipment measuring the > transition between the two hyperfine levels of the ground state of the > caesium 133 atom. Gravitational Sphere of Influence of the 99942 Apophis on > the Gravitational orbit of GPS satelites (Still having a higher probability > than hash-collisions ;-)), Drunk Sysadmins, Rouge Registrar, etc, etc. > > I'm sure that it will be a very large section. Precisely. I realize it's hard to grasp precisely how small the statistical chances of a collision are, but they are just unbelievably small. Acting as if it is something that might actually happen just makes you look silly. -Ekr ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Feb 22, 2010, at 11:12 AM, Evan Hunt wrote: >> Using NSEC instead of NSEC3 because you fear SHA1 collisions does not >> seem sensible, as if you fear SHA1 collisions, you have other more >> significant problems with DNSSEC to worry about, and thus this is >> not, in my opinion, reasonable. And it isn't sensible to suggest >> users worry about it. If we are going to mention it, it should be >> in security considerations, saying NSEC3 is dependent upon certain >> properties of its hash algorithm (I forget now whether it is >> collision resistance, pre-image resistance or or what), but this >> should also point out the whole of DNSSEC is predicated on similar >> qualities. > > +1 except for the "if". It is mathematically possible for collisions to > occur with one approach and not the other, and it would be irresponsible > not to make note of the fact, even if we agree that the chances of this > occurring in nature are negligible. This is absurd. If we're going to do this, I'd like the security considerations to reflect all of the non-zero probabilities of errors occuring (those that have a higher probability). This includes software-bugs, hardware-bugs, probability of advances in factorization, randomness of PRNG for DNSKEYs, faulty calibration/low granularity of equipment measuring the transition between the two hyperfine levels of the ground state of the caesium 133 atom. Gravitational Sphere of Influence of the 99942 Apophis on the Gravitational orbit of GPS satelites (Still having a higher probability than hash-collisions ;-)), Drunk Sysadmins, Rouge Registrar, etc, etc. I'm sure that it will be a very large section. Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
At 11:17 -0500 2/22/10, Matt Larson wrote: +1, total and complete agreement. I am adamantly opposed to including any text about SHA1 hash collisions in an NSEC3 context. I'll agree. We are using NSEC in dotUS and not NSEC3. It wasn't because of the risk of hash collisions in SHA1. We didn't even get close to considering that. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Sun, 21 Feb 2010, Eric Rescorla wrote:
> On Sun, Feb 21, 2010 at 4:22 PM, Mark Andrews wrote:
> > Actually NSEC is technically better at proving non-existance. NSEC3
> > has a non zero false positive rate due to the fact that the names
> > are hashed. NSEC has a zero false positive rate.
> >
> > This is not to say the false positive rate is high enough to stop
> > using NSEC3, but that it needs to be acknowledged.
>
> Unless I'm misreading the specifications, unless you're using an extremely
> poor or short hash function, the probability of false positive is vanishingly
> small (order 2^{-100}). This shouldn't be acknowledged, but rather
> should be ignored. Moreover, it appears that NSEC3 has a mechanism
> for dealing with it in S C.2.1 (pointless, IMO...)
>
> So, I don't see what the issue is.
+1, total and complete agreement. I am adamantly opposed to including
any text about SHA1 hash collisions in an NSEC3 context.
Matt
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
> Using NSEC instead of NSEC3 because you fear SHA1 collisions does not > seem sensible, as if you fear SHA1 collisions, you have other more > significant problems with DNSSEC to worry about, and thus this is > not, in my opinion, reasonable. And it isn't sensible to suggest > users worry about it. If we are going to mention it, it should be > in security considerations, saying NSEC3 is dependent upon certain > properties of its hash algorithm (I forget now whether it is > collision resistance, pre-image resistance or or what), but this > should also point out the whole of DNSSEC is predicated on similar > qualities. +1 except for the "if". It is mathematically possible for collisions to occur with one approach and not the other, and it would be irresponsible not to make note of the fact, even if we agree that the chances of this occurring in nature are negligible. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
--On 22 February 2010 14:41:19 +0100 "W.C.A. Wijngaards" wrote: I am not saying this makes NSEC3 a unchoosable option; but it is a tradeoff, and if you can use NSEC because you do not need the benefits of NSEC3, you should, because it'll drive down bandwidth and cpu usage (slightly) for everyone. Using NSEC instead of NSEC3 for the above reasons seems sensible. Using NSEC instead of NSEC3 also seems sensible if you don't need NSEC3 features for reasons like ease of debugging (as the zone file is more readable) and fear of implementation bugs from increased complexity also seems reasonable. Using NSEC instead of NSEC3 because you fear SHA1 collisions does not seem sensible, as if you fear SHA1 collisions, you have other more significant problems with DNSSEC to worry about, and thus this is not, in my opinion, reasonable. And it isn't sensible to suggest users worry about it. If we are going to mention it, it should be in security considerations, saying NSEC3 is dependent upon certain properties of its hash algorithm (I forget now whether it is collision resistance, pre-image resistance or or what), but this should also point out the whole of DNSSEC is predicated on similar qualities. Note the current draft already recommends NSEC if you don't need NSEC3 (for reasons other than fear of hash collisions). I am entirely happy with that. -- Alex Bligh ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Roy, On 02/22/2010 02:14 PM, Roy Arends wrote: > Nah, we love collisions, it makes it all so more efficient. Besides, > I think the probability of finding a bug in authoritative server > software is way higher than a hash-collision. Yes, I agree that it is very unlikely. (And I wouldn't mind a 2**-100 chance of bugs in my software :-) ). If there ever are multiple NSEC3-hash-algorithm choices, the 'hash collision' resistance is a factor. NSEC, by virtue of its design cannot have these hash collisions (but then it does not hash either). >> But I agree more pertinent to choice is the increased CPU demand >> and larger packets when using NSEC3. And opt-out, obfuscation >> desiderata. > > All FUD. I actually thought those were the choices, was I wrong in that assessment? SHA-1 hashes take time, and NSEC3 responses are larger (mostly because you need 3 records instead of 2 for the common case and the extra signature counts, not actually the NSEC3 itself is that much larger). I am not saying this makes NSEC3 a unchoosable option; but it is a tradeoff, and if you can use NSEC because you do not need the benefits of NSEC3, you should, because it'll drive down bandwidth and cpu usage (slightly) for everyone. Best regards, Wouter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkuCiX8ACgkQkDLqNwOhpPhXxACeMb7HH57cvczT41QMopDfiAtj skMAoIOK83bylZ4x6VqRrB1FEoLkNvhs =1MC1 -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Feb 22, 2010, at 8:14 AM, Roy Arends wrote: > example.co.uk (lets skip the probability factor), than its just gotten a bit > more efficient. One hash matching 2 names, i.e. we can now deny two names for > the price of one. can now prove existence of two names for the price of one. Now... coffee. Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Feb 22, 2010, at 4:44 AM, W.C.A. Wijngaards wrote: > On 02/22/2010 04:53 AM, Roy Arends wrote: >> On Feb 21, 2010, at 7:22 PM, Mark Andrews wrote: >> >>> NSEC3 >>> has a non zero false positive rate due to the fact that the names >>> are hashed. >> >> Are you going on again about the possibility of hash collisions is SHA-1? > > Yes. +1 for Marks point. > > The deployment of NSEC3-signed toplevel domains is a giant hash > collision test of typo dictionaries. Not really, most (will) use Opt-Out. > What does the registry do when > someone registers a new domain name that has a hash-collision We'll claim that sha-1 is broken, write a paper on it and have our 15 minutes of fame. Meanwhile... In the real world, if someone registers the name 759345ihkjgrj345837458fjfgiusifghgvtsrhf8hfvihi.co.uk and its hash collides with example.co.uk (lets skip the probability factor), than its just gotten a bit more efficient. One hash matching 2 names, i.e. we can now deny two names for the price of one. The real problem is that a SHA1 hash collision would render all signatures with RSASHA1 vulnerable. Haven't heard you about that. I suggest that if you and Andrews want to have this claim rfc4641bis, you should not discriminate on NSEC3, but on everything that uses SHA1. > (resign > with a new salt, and also keep that 2-second update guarantee? - I would > suggest some weasel words in agreements). Nah, we love collisions, it makes it all so more efficient. Besides, I think the probability of finding a bug in authoritative server software is way higher than a hash-collision. > But I agree more pertinent to choice is the increased CPU demand and > larger packets when using NSEC3. And opt-out, obfuscation desiderata. All FUD. Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/22/2010 04:53 AM, Roy Arends wrote: > On Feb 21, 2010, at 7:22 PM, Mark Andrews wrote: > >> NSEC3 >> has a non zero false positive rate due to the fact that the names >> are hashed. > > Are you going on again about the possibility of hash collisions is SHA-1? Yes. +1 for Marks point. The deployment of NSEC3-signed toplevel domains is a giant hash collision test of typo dictionaries. What does the registry do when someone registers a new domain name that has a hash-collision (resign with a new salt, and also keep that 2-second update guarantee? - I would suggest some weasel words in agreements). But I agree more pertinent to choice is the increased CPU demand and larger packets when using NSEC3. And opt-out, obfuscation desiderata. Best regards, Wouter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkuCUegACgkQkDLqNwOhpPj3iQCgjlOEE8nJFUfj42DDFV3BOrn7 CkUAnjSpyN/UgQrUW0n7X3bq9VxdD763 =K2rl -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Sun, Feb 21, 2010 at 4:22 PM, Mark Andrews wrote:
>
> In message <315ad36e-879a-4512-a6a8-b64372e3d...@sinodun.com>, John Dickinson
> w
> rites:
>> Hi,
>>
>> It might also be worth adding a line at the start reminding of the need for N
>> SEC and NSEC3 - namely that the signing and serving of the zone are separate
>> operations and that it is therefore necessry to create records that cover the
>> very large number of non-existent names that lie between the names that do e
>> xist.
>>
>> NSEC and NSEC3 are just different ways to achieve this goal and some people m
>> ight prefer one above the other. One is NOT better than the other and it is a
>> matter of operational needs that determine which one you select.
>>
>> It may also be worth removing the mention of cryptographic operations. The ha
>> shing in NSEC3 is just a way to create new names that cover the same spaces.
>> I imagine that many other schemes could have been dreamt up to do this. Hashi
>> ng is just a convenient method.
>>
>> John
>
> Actually NSEC is technically better at proving non-existance. NSEC3
> has a non zero false positive rate due to the fact that the names
> are hashed. NSEC has a zero false positive rate.
>
> This is not to say the false positive rate is high enough to stop
> using NSEC3, but that it needs to be acknowledged.
Unless I'm misreading the specifications, unless you're using an extremely
poor or short hash function, the probability of false positive is vanishingly
small (order 2^{-100}). This shouldn't be acknowledged, but rather
should be ignored. Moreover, it appears that NSEC3 has a mechanism
for dealing with it in S C.2.1 (pointless, IMO...)
So, I don't see what the issue is.
-Ekr
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Feb 21, 2010, at 7:22 PM, Mark Andrews wrote: > NSEC3 > has a non zero false positive rate due to the fact that the names > are hashed. Are you going on again about the possibility of hash collisions is SHA-1? Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
In message <315ad36e-879a-4512-a6a8-b64372e3d...@sinodun.com>, John Dickinson w rites: > Hi, > > It might also be worth adding a line at the start reminding of the need for N > SEC and NSEC3 - namely that the signing and serving of the zone are separate > operations and that it is therefore necessry to create records that cover the > very large number of non-existent names that lie between the names that do e > xist. > > NSEC and NSEC3 are just different ways to achieve this goal and some people m > ight prefer one above the other. One is NOT better than the other and it is a > matter of operational needs that determine which one you select. > > It may also be worth removing the mention of cryptographic operations. The ha > shing in NSEC3 is just a way to create new names that cover the same spaces. > I imagine that many other schemes could have been dreamt up to do this. Hashi > ng is just a convenient method. > > John Actually NSEC is technically better at proving non-existance. NSEC3 has a non zero false positive rate due to the fact that the names are hashed. NSEC has a zero false positive rate. This is not to say the false positive rate is high enough to stop using NSEC3, but that it needs to be acknowledged. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
Hi, It might also be worth adding a line at the start reminding of the need for NSEC and NSEC3 - namely that the signing and serving of the zone are separate operations and that it is therefore necessry to create records that cover the very large number of non-existent names that lie between the names that do exist. NSEC and NSEC3 are just different ways to achieve this goal and some people might prefer one above the other. One is NOT better than the other and it is a matter of operational needs that determine which one you select. It may also be worth removing the mention of cryptographic operations. The hashing in NSEC3 is just a way to create new names that cover the same spaces. I imagine that many other schemes could have been dreamt up to do this. Hashing is just a convenient method. John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On 2/20/2010 8:48 AM, Paul Wouters wrote: On Sat, 20 Feb 2010, Alex Bligh wrote: There are two meachanisms to provide authenticated proof of exsitance/non-existance in DNSSEC. I don't believe either provides proof of existence (apart from existence of the NSECx record). Yep - agreed. If you can proof one, you can also proof the other :) Not so - and its prove. The issue is that technical proofs and legal proofs are NOT the same thing anywhere but here before the IETF making them worthless in Courts. Todd Glassey I think they both only provide proof of non-existence (and in the case of NSEC3 opt out, not even that). That I agree with. NSEC3 plus OPT-OUT does not give a full authenticated proof of non-existance. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.435 / Virus Database: 271.1.1/2698 - Release Date: 02/19/10 19:34:00 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
Thanks Evan and Andrew fot translating my thoughts into better prose. Evan, you captures my meaning. Olafur On 20/02/2010 4:31 PM, Evan Hunt wrote: I think Olafur's point is a good one, but I'm unhappy with the prose. Some suggested changes below. Same here. Nits: There are to mechanisms to provide authenticated proof of s/to/two/ Each mechanism includes a list of all the RRTYPEs present at the s/includes/stores/ The clear text version has its one RRtype for negative answer, Clear text one uses NSEC record and the obfuscated one used NSEC3. I didn't know how to rephrase that, because if I understand it I think what I understand is wrong (but that's obviously not the case, so probably I don't understand it). I think he meant "each version has its own RRtype". Suggested change: "Each mechanism uses a specific RRTYPE to store information about the RRTYPEs present at the name: the clear-text mechanism uses NSEC, and the obfuscated-data mechanism uses NSEC3." It may also be worth mentioning that the two mechanisms are usually referred to by the names of their corresponding RR types. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
> I think Olafur's point is a good one, but I'm unhappy with the prose. > Some suggested changes below. Same here. Nits: > There are to mechanisms to provide authenticated proof of s/to/two/ > Each mechanism includes a list of all the RRTYPEs present at the s/includes/stores/ > > The clear text version has its one RRtype for negative answer, Clear > > text one uses NSEC record and the obfuscated one used NSEC3. > > I didn't know how to rephrase that, because if I understand it I think > what I understand is wrong (but that's obviously not the case, so > probably I don't understand it). I think he meant "each version has its own RRtype". Suggested change: "Each mechanism uses a specific RRTYPE to store information about the RRTYPEs present at the name: the clear-text mechanism uses NSEC, and the obfuscated-data mechanism uses NSEC3." It may also be worth mentioning that the two mechanisms are usually referred to by the names of their corresponding RR types. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
I think Olafur's point is a good one, but I'm unhappy with the prose. Some suggested changes below. On Sat, Feb 20, 2010 at 08:37:16AM -0500, Olafur Gudmundsson wrote: > There are two meachanisms to provide authenticated proof of > exsitance/non-existance in DNSSEC. A clear text one and a obfuscated > one. There are to mechanisms to provide authenticated proof of non-existence in DNSSEC: a clear text one and an obfuscated-data one. Each mechanism includes a list of all the RRTYPEs present at the name. Each mechanism includes only the name for which the zone is authoritative (that is, glue in the zone is omitted). The clear text mechanism is implemented using a sorted linked list of names in the zone. The obfuscated-data mechanism first hashes the names using a one-way hash function, and then sorts the resulting (hashed) strings. > The clear text version has its one RRtype for negative answer, Clear > text one uses NSEC record and the obfuscated one used NSEC3. I didn't know how to rephrase that, because if I understand it I think what I understand is wrong (but that's obviously not the case, so probably I don't understand it). A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Sat, 20 Feb 2010, Alex Bligh wrote: There are two meachanisms to provide authenticated proof of exsitance/non-existance in DNSSEC. I don't believe either provides proof of existence (apart from existence of the NSECx record). If you can proof one, you can also proof the other :) I think they both only provide proof of non-existence (and in the case of NSEC3 opt out, not even that). That I agree with. NSEC3 plus OPT-OUT does not give a full authenticated proof of non-existance. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
--On 20 February 2010 08:37:16 -0500 Olafur Gudmundsson wrote: There are two meachanisms to provide authenticated proof of exsitance/non-existance in DNSSEC. I don't believe either provides proof of existence (apart from existence of the NSECx record). I think they both only provide proof of non-existence (and in the case of NSEC3 opt out, not even that). -- Alex Bligh ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
5. Next Record type There are currently two types of next records that are provide authenticated denial of existence of DNS data in a zone. I have a problem with this presentation. There are two mechanishm to provide proof of non-existance, each has a RR type associated with it. The text of section 5 as written places the RRtype as the main focus rather than the technique used. One of the issues I have been running into is that people assume that NSEC3 is a replacement of NSEC because of the naming of the records i.e. NSEC3 is 3'rd version of NSEC ; For this reason I would advoacte that this section be retuned to talk about the mechanishms first then cover the on the wire details and records. o The NSEC [4] record builds a linked list of sorted RRlabels with their record types in the zone. o The NSEC3 [24] record builds a similar linked list, but uses hashes instead of the RRLabels. My draft rewrite of 5. There are two meachanisms to provide authenticated proof of exsitance/non-existance in DNSSEC. A clear text one and a obfuscated one. Both mechanishms for each name include a list of all the RRtypes present at the name. Both mechanishms only include the names the zone is authoratitve, i.e. glue names present in the zone are omiited. * The clear text one is implemented via a sorted link list of names in the zone. * The obufscated first hashes the names via one-way hash function and then sorts the resulting strings. The clear text version has its one RRtype for negative answer, Clear text one uses NSEC record and the obfuscated one used NSEC3. If you agree with this change in focus is benefital I will be happy to help rewrite the remainder of the section. Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
5.2. NSEC or NSEC3
The first reason to deploy NSEC3, prevention of zone enumeration,
makes sense when zone content is not highly structured or trivially
"only makes sense" ?
How about "applies"
The algorithm choice therefor depends solely on the DNSKEY algorithm
picked.
"The next record algorithm choice therefor." to make it less
confusing?
"therefore" not "therefor" (I'm pretty sure that's not one the
USA does differently).
("therefore" means "for that reason", "therefor" means "for that"
and is archaic)
The NSEC3 hashing includes the FQDN in its uncompressed form. This
"over its uncompressed form"? The hash does not 'include' it.
how about "the NSEC3 hash is performed over data including the FQDN in its
uncompressed form"
--
Alex Bligh
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/17/2010 05:37 PM, Paul Wouters wrote: 5.3. NSEC3 parameters The NSEC3 hashing includes the FQDN in its uncompressed form. This >>> >>> "over its uncompressed form"? The hash does not 'include' it. >> >> I overlooked this when I copied the text from P.W. who originally >> supplied it :-) >> >> How about "hashing algorithm is performed on the FQDN ..." > > Works for me. Does not work for me, because the salt is also included in the hash, the old text was technically true because the buffer that is hashed has the FQDN as a substring. Can the line be removed? Otherwise, change active vs passive: The uncompressed FQDN is used for the NSEC3 hash. Best regards, Wouter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkt8IG0ACgkQkDLqNwOhpPgxIgCfQTMxa2SVQi/9McXVeRYszMQm L8YAnRWH9UCHyIu09bnVO98xbkU/MW+M =y4LW -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Wed, 17 Feb 2010, Olaf Kolkman wrote: Small typos: "enumerated" and "sequential queries" I am not sure about the "should" in that sentence either. How about "is accessable through query mechanisms"? That works for me. Also, during further editing I have changed the tone of the paragraph a bit: Instead of "reasons for development" I mention the differences and don't claim them to be motivations. There are probably many views on the history on how NSEC3 and OPT-OUT came about and I don;t want to waist time on arguing about those views on history. Ok. "at the expense of some deniability"? I feel we need to make it clear here that there is a trade-of. Opt-out isn't all positive. It has a price. I turned that into: " at the expense of the abillity to cryptographically deny the existence of names in a specific span." Ok. The first reason to deploy NSEC3, prevention of zone enumeration, makes sense when zone content is not highly structured or trivially "only makes sense" ? I think that is right. I cannot come up with occasions whereby those conditions hold and NSEC3 as a prevention for zone enumeration is still a smart thing to do. I meant it has a linguistic change, not a content change. Without the "only" the setence is a bit difficult to read for me. 5.3. NSEC3 parameters The NSEC3 hashing includes the FQDN in its uncompressed form. This "over its uncompressed form"? The hash does not 'include' it. I overlooked this when I copied the text from P.W. who originally supplied it :-) How about "hashing algorithm is performed on the FQDN ..." Works for me. 5.3.3. NSEC3 Salt The salt with NSEC3 is not used to increase the work required by an attacker attacking multiple domains, but as a method to enable creating a new set of hash values if at some point that might be required. The salt is used as a "roll over". I would throw this around. No, you would not, at least you didn't the first time around the initial text was yours (or am I seriously wrong and acknowledging the wrong person for this significant contribution?) It obviously sat too long in your inbox then. But I'm more then happy to correct myself :) Don't start saying what the salt is not for, but say what it is for. I like this suggestion! First: Key rollovers limit the amount of time attackers can spend on attacking a certain key before it is retired. The salt serves the same purpose for the hashes, which are independant of the key being used, and therefor do not change when rolling over a key. Changing the salt would cause an attacker to lose all precalculated work for that zone. I changed the implementation a bit, given the abundant amount of discussion about key rollovers (which I will try to turn into concrete text) I want to not make that parallel. Okay. delegations within the span. [Editors Note: One could make this construct more correct by talking about the hashed names and the hashed span, but I believe that is overkill]. If you think of protecting typosquatting domain spoofs, it might be important to realise that the span is over hashes, and not over "most domains that resemble your domain"? I understand what you mean but how important is it to build this argument comprehensively? Ok. I'll leave it up to you. It is not that important. Remaining dump looked good. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Feb 17, 2010, at 4:03 PM, Paul Wouters wrote: > On Wed, 17 Feb 2010, Olaf Kolkman wrote: > >> Though all agree DNS data should be accessible through query >> mechanisms, a side effect of NSEC is that it allows the contents of a >> zone file to be enumerate in full by sequential query. Whilst for > > Small typos: "enumerated" and "sequential queries" > > I am not sure about the "should" in that sentence either. How about "is > accessable through query mechanisms"? That works for me. Also, during further editing I have changed the tone of the paragraph a bit: Instead of "reasons for development" I mention the differences and don't claim them to be motivations. There are probably many views on the history on how NSEC3 and OPT-OUT came about and I don;t want to waist time on arguing about those views on history. > > >> delegations). NSEC3 allows intervals between two such delegations to >> "Opt-out" in which case they may contain one more more insecure >> delegations, thus reducing the size and cryptographic complexity of >> the zone. > > "at the expense of some deniability"? I feel we need to make it clear > here that there is a trade-of. Opt-out isn't all positive. It has a > price. > I turned that into: " at the expense of the abillity to cryptographically deny the existence of names in a specific span." >> 5.2. NSEC or NSEC3 >> >> The first reason to deploy NSEC3, prevention of zone enumeration, >> makes sense when zone content is not highly structured or trivially > > "only makes sense" ? I think that is right. I cannot come up with occasions whereby those conditions hold and NSEC3 as a prevention for zone enumeration is still a smart thing to do. > >> 5.3. NSEC3 parameters >> >> The NSEC3 hashing includes the FQDN in its uncompressed form. This > > "over its uncompressed form"? The hash does not 'include' it. I overlooked this when I copied the text from P.W. who originally supplied it :-) How about "hashing algorithm is performed on the FQDN ..." > >> 5.3.1. NSEC3 Algorithm >> >> The NSEC3 algorithm is specified as a version of the DNSKEY >> algorithm. The current options are: >> >> Algorithm 6, DSA-NSEC3-SHA1 is an alias for algorithm 3, DSA. >> >> Algorithm 7, RSASHA1-NSEC3-SHA1 is an alias for algorithm 5, >> RSASHA1. >> >> The algorithm choice therefor depends solely on the DNSKEY algorithm >> picked. > > "The next record algorithm choice therefor." to make it less confusing? Ack >> 5.3.3. NSEC3 Salt >> >> The salt with NSEC3 is not used to increase the work required by an >> attacker attacking multiple domains, but as a method to enable >> creating a new set of hash values if at some point that might be >> required. The salt is used as a "roll over". > > I would throw this around. No, you would not, at least you didn't the first time around the initial text was yours (or am I seriously wrong and acknowledging the wrong person for this significant contribution?) > Don't start saying what the salt is not for, > but say what it is for. I like this suggestion! > First: > > Key rollovers limit the amount of time attackers can spend on > attacking a certain key before it is retired. The salt serves the > same purpose for the hashes, which are independant of the key being > used, and therefor do not change when rolling over a key. Changing > the salt would cause an attacker to lose all precalculated work for > that zone. I changed the implementation a bit, given the abundant amount of discussion about key rollovers (which I will try to turn into concrete text) I want to not make that parallel. > And then: > > The FQDN RRlabel, > which is part of the value that is hashed, already ensures that brute > force work for one RRlabel can not be re-used to attack other RRlabel > due to their uniquenes. > >> The salt of all NSEC3 records in a zone needs to be the same. Since >> changing the salt requires the NSEC3 records to be regenerated, and >> thus requires generating new RRSIG's over these NSEC3 records, it is >> recommended to only change the salt when changing the Zone Signing >> Key, as that process in itself already requires all RRSIG's to be >> regenerated. I did some editing and rewriting. See the full dump below. > > Should there be any explanation about the NSEC3PARAM record here? Not sure yet, I take WG guidance. > >> The Opt-Out mechanism was introduced to allow for a gradual >> introduction of signed records in zones that contain mostly >> delegation records. The use of the OPT-OUT flag changes the meaning >> of the NSEC3 span from authoritative denial of the existence of names >> within the span to a proof that DNSSEC is not available for the >> delegations within the span. [Editors Note: One could make this >> construct more correct by talking about the hashed names and the >> hashed span, but I believe that is overkill]. > > If you think
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Wed, 17 Feb 2010, Olaf Kolkman wrote: Though all agree DNS data should be accessible through query mechanisms, a side effect of NSEC is that it allows the contents of a zone file to be enumerate in full by sequential query. Whilst for Small typos: "enumerated" and "sequential queries" I am not sure about the "should" in that sentence either. How about "is accessable through query mechanisms"? delegations). NSEC3 allows intervals between two such delegations to "Opt-out" in which case they may contain one more more insecure delegations, thus reducing the size and cryptographic complexity of the zone. "at the expense of some deniability"? I feel we need to make it clear here that there is a trade-of. Opt-out isn't all positive. It has a price. 5.2. NSEC or NSEC3 The first reason to deploy NSEC3, prevention of zone enumeration, makes sense when zone content is not highly structured or trivially "only makes sense" ? 5.3. NSEC3 parameters The NSEC3 hashing includes the FQDN in its uncompressed form. This "over its uncompressed form"? The hash does not 'include' it. 5.3.1. NSEC3 Algorithm The NSEC3 algorithm is specified as a version of the DNSKEY algorithm. The current options are: Algorithm 6, DSA-NSEC3-SHA1 is an alias for algorithm 3, DSA. Algorithm 7, RSASHA1-NSEC3-SHA1 is an alias for algorithm 5, RSASHA1. The algorithm choice therefor depends solely on the DNSKEY algorithm picked. "The next record algorithm choice therefor." to make it less confusing? 5.3.3. NSEC3 Salt The salt with NSEC3 is not used to increase the work required by an attacker attacking multiple domains, but as a method to enable creating a new set of hash values if at some point that might be required. The salt is used as a "roll over". I would throw this around. Don't start saying what the salt is not for, but say what it is for. First: Key rollovers limit the amount of time attackers can spend on attacking a certain key before it is retired. The salt serves the same purpose for the hashes, which are independant of the key being used, and therefor do not change when rolling over a key. Changing the salt would cause an attacker to lose all precalculated work for that zone. And then: The FQDN RRlabel, which is part of the value that is hashed, already ensures that brute force work for one RRlabel can not be re-used to attack other RRlabel due to their uniquenes. The salt of all NSEC3 records in a zone needs to be the same. Since changing the salt requires the NSEC3 records to be regenerated, and thus requires generating new RRSIG's over these NSEC3 records, it is recommended to only change the salt when changing the Zone Signing Key, as that process in itself already requires all RRSIG's to be regenerated. Should there be any explanation about the NSEC3PARAM record here? The Opt-Out mechanism was introduced to allow for a gradual introduction of signed records in zones that contain mostly delegation records. The use of the OPT-OUT flag changes the meaning of the NSEC3 span from authoritative denial of the existence of names within the span to a proof that DNSSEC is not available for the delegations within the span. [Editors Note: One could make this construct more correct by talking about the hashed names and the hashed span, but I believe that is overkill]. If you think of protecting typosquatting domain spoofs, it might be important to realise that the span is over hashes, and not over "most domains that resemble your domain"? Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
Alex, I have taken your recommendations and added them to the current text. Also the other discussion about enumarability of highly structured zones found a place. However, I did do some slight rephrasing. I don't think I changed the spirit of your suggestions. The text in my current draft can be found below. --Olaf > > > --On 22 January 2010 12:04:07 +0100 Olaf Kolkman wrote: > > Strawman text said: >> Though some claim all data in the DNS should be considered public, it >> sometimes is considered to be more then private, but less then public >> data. > > That does not describe the problem well, in that (1) it is not > the data that is somewhere between public and private, it is > that the mechanisms of access to that data that change, and (2) it > completely ignores opt-out. How about > > Though all agree DNS data should be accessible through query > mechanisms, a side effect of NSEC is that it allows the contents of > a zone file to be enumerate in full by sequential query. Whilst for > some operators this behaviour is acceptable or even desirable, for > others it is undesirable for policy, regulatory or other reasons. > This is the first reason for development of NSEC3. > > The second reason for the existence of NSEC3 is that NSEC requires > a signature over every RR in the zonefile, thereby ensuring that > any denial of existence is cryptographically signed. However, in a > large zonefile containing many delegations very few of which are to > signed zones, this may produce unacceptable additional overhead > especially where insecure delegations are subject to frequent > update (a typical example might be a TLD operator with few > registrants using secure delegations). NSEC3 allows intervals > between two such delegations to "Opt-out" in which case they may > contain one more more insecure delegations, thus reducing the size > and cryptographic complexity of the zone. > >> 5.3.4 Opt-out >> >> An Opt-Out NSEC3 RR does not assert the existence or non-existence of the >> insecure delegations that it may cover. This allows for the addition or >> removal of these delegations without recalculating or re- signing RRs in >> the NSEC3 RR chain. Therefor, Opt-Out should be avoided if possible. > > 1. Therefor*e* > > 2. I don't think the last sentence follows from the foregoing, in that > this behaviour is desirable for the zone operator! (I know what > you mean). > > 3. Aside from that, I don't think an injunction to avoid Opt-Out in > these terms is sensible in a delegation only zone. In such a zone, > I don't really see the additional security risk from opt out across > insecure delegations, given if a spoof can be done, it can be > done at the delegated zone level. There are considerable operational > advantages in Opt Out (zone size, cryptographic complexity etc.) > for large zones only sparsely populated with secure delegations, > particularly where few queries have DO set anyway. > > -- > Alex Bligh [...] 5. Next Record type There are currently two types of next records that are provide authenticated denial of existence of DNS data in a zone. o The NSEC [4] record builds a linked list of sorted RRlabels with their record types in the zone. o The NSEC3 [24] record builds a similar linked list, but uses hashes instead of the RRLabels. 5.1. Reasons for the existence of NSEC and NSEC3 The NSEC record requires no cryptographic operations aside from validating its associated signature record. It is human readable and can be used in manual queries to determin correct operation. The disadvantage is that it allows for "zone walking", where one can request all the entries of a zone by following the next RRlabel pointed to in each subsequent NSEC record. Kolkman & GiebenExpires September 8, 2009 [Page 31] Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 Though all agree DNS data should be accessible through query mechanisms, a side effect of NSEC is that it allows the contents of a zone file to be enumerate in full by sequential query. Whilst for some operators this behaviour is acceptable or even desirable, for others it is undesirable for policy, regulatory or other reasons. This is the first reason for development of NSEC3. The second reason for the existence of NSEC3 is that NSEC requires a signature over every RR in the zonefile, thereby ensuring that any denial of existence is cryptographically signed. However, in a large zonefile containing many delegations very few of which are to signed zones, this may produce unacceptable additional overhead especially where insecure delegations are subject to frequent update (a typical example might be a TLD operator with few registrants using secure delegations). NSEC3 allows intervals
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Sat, Jan 23, 2010 at 08:00:17PM -0500, Matt Larson wrote: > On Fri, 22 Jan 2010, Paul Wouters wrote: > > On Fri, 22 Jan 2010, Alex Bligh wrote: > >> I meant computational resource requirements resultant from crypto > >> operations, not algorithmic complexity. > > > > I had no problems doing this on a 1.2M domains TLD zone, using off the > > shelf hardware, integrating into the TLD's hourly update interval. > > (http://www.cira.ca/dnssec/) > > Try 100M delegations, updated every 15 seconds, and sending the > resulting large non-Opt-out zone to places with poor connectivity such > as Nairobi, Kenya. > > Arguments such as "I did it on once on commodity hardware with freely > available tools" or "you can implement that in an afternoon" do not > transfer well to large, critically important TLDs (or any large-scale, > critical service). > > Matt to be honest, there are a few more delegation points that fit the 1.xM domains using cots technology than there are delegations that have delegations with 100M+ entries and running dynamic udates. on more than one occasion (perhaps first at the IETF in SLC) I have heard folks who would like the business model of such a delegation refer to it as "a goiter on the neck of the DNS" in envy. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Fri, 22 Jan 2010, Paul Wouters wrote: > On Fri, 22 Jan 2010, Alex Bligh wrote: >> I meant computational resource requirements resultant from crypto >> operations, not algorithmic complexity. > > I had no problems doing this on a 1.2M domains TLD zone, using off the > shelf hardware, integrating into the TLD's hourly update interval. > (http://www.cira.ca/dnssec/) Try 100M delegations, updated every 15 seconds, and sending the resulting large non-Opt-out zone to places with poor connectivity such as Nairobi, Kenya. Arguments such as "I did it on once on commodity hardware with freely available tools" or "you can implement that in an afternoon" do not transfer well to large, critically important TLDs (or any large-scale, critical service). Matt ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
--On 23 January 2010 12:25:00 -0500 Olafur Gudmundsson wrote: Opt-out was designed for large delegation-only/mostly zones, in almost all other cases it should not be used. And this was the only use case I was suggesting was excepted from the blanket "should not" (in fact I went further and said it should only apply to large delegation-only/mostly zones where secure delegations were sparse). -- Alex Bligh ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
At 15:54 22/01/2010, Alex Bligh wrote: --On 22 January 2010 15:45:54 -0500 Edward Lewis wrote: contents) in example.org. So, whilst opt-out should be avoided across intervals containing secure delegations, I see no reason to avoid it across intervals that don't contain secure delegations. Opt-out is restricted to "intervals" that contain only unsecured delegations. Doh! Yes indeed. In which case I stand by my original argument: I can't see how opt-out really increase spoofability. It can't affect a secure delegation, and the contents of an insecure delegation or denial thereof (if not the delegation itself) are spoofable with or without opt-out. Paul's example of a secure delegation with opt-out across it can't exist. Lets say example is signed, bank.example is signed using NSEC3 with opt-out in one span to hide one division. Lets say secure.bank.example by co-incidence falls into the opt-ed-out gap. Now a phisher can attempt to insert an insecure delegation called secure.bank.example into caches and send mails telling people to visit this site to claim their price Opt-out was designed for large delegation-only/mostly zones, in almost all other cases it should not be used. The use of NSEC vs NSEC3 in zone is a different discussion. A zone that contains guess-able names gains almost nothing from using NSEC3. A zone operator may still feel better using NSEC3 :-) If you really want to hide the content of your zone only epsilon signing will work RFC4470+RFC4471. Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
--On 23 January 2010 04:56:33 + Alex Bligh wrote: Having verifiable deniability for typo-squated domaims is very useful. If expensive, where 99% of your domains are unsigned. By which I mean expensive given this isn't the cheapest attack vector. If I want to typo squat with a non-existent domain (and it's only non-existent domains where verification of denial of existence is an issue), I could just register the domain which would be far more reliable than all the hocus pocus needed to get spoofing to work. It's not that hard to get an SSL cert either. And if I have got the technology to spoof, why not attack one of the 99% unsigned domains in the zone, rather than an unregistered typo-squat of a signed one, as the pickings will be far greater? -- Alex Bligh ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
Paul, I was talking about the situation where example.org is signed, the .org is optout and exemple.org does not exist. For many, it is impossible to register all typo-squat domains, so this is a real scenario. Ah, didn't spot the 'e'. Having verifiable deniability for typo-squated domaims is very useful. If expensive, where 99% of your domains are unsigned. I had no problems doing this on a 1.2M domains TLD zone, using off the shelf hardware, integrating into the TLD's hourly update interval. (http://www.cira.ca/dnssec/) The only issues encountered were indeed the increased memory usage on the nameservers, but those can still run fine on commodity hardware. Though I recommend 64bit to avoid and 3G or 4G memory allocation per process issues. And on a 100M TLD zone that needs near real time updates? I don't know whether zone growth predictions exceed Moore's law or vice versa, to see whether this is a growing problem or not. I agree that the computational complexity argument is a minority problem. It might be worth mentioning (but is perhaps blindingly obvious) that NSEC3 is substantially more complex in terms of implementation than NSEC. Whilst one can by visual inspection spot the odd problem with a small zone's NSEC chain, it's far harder with NSEC3. Obviously, if a tool chain is used to NSECify and sign the zone, that's a problem for the implementor rather than the operator. Commercial and free tools are readilly available. Sure. Just rehearsing an argument I've heard others use against NSEC3. -- Alex Bligh ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Fri, 22 Jan 2010, Alex Bligh wrote: If I secure example.org, and .org is signed, OPT-OUT might cause a spoofed exemple.org to not be caught by the user's validating resolver. Therefor, I do think opt-out should be avoided when possible. If I run .org, which is signed, but example.org is NOT signed (i.e. I was talking about the situation where example.org is signed, the .org is optout and exemple.org does not exist. For many, it is impossible to register all typo-squat domains, so this is a real scenario. is an unsigned delegation), there seems to be little reason to avoid opt out across it. Having verifiable deniability for typo-squated domaims is very useful. I meant computational resource requirements resultant from crypto operations, not algorithmic complexity. I had no problems doing this on a 1.2M domains TLD zone, using off the shelf hardware, integrating into the TLD's hourly update interval. (http://www.cira.ca/dnssec/) The only issues encountered were indeed the increased memory usage on the nameservers, but those can still run fine on commodity hardware. Though I recommend 64bit to avoid and 3G or 4G memory allocation per process issues. It might be worth mentioning (but is perhaps blindingly obvious) that NSEC3 is substantially more complex in terms of implementation than NSEC. Whilst one can by visual inspection spot the odd problem with a small zone's NSEC chain, it's far harder with NSEC3. Obviously, if a tool chain is used to NSECify and sign the zone, that's a problem for the implementor rather than the operator. Commercial and free tools are readilly available. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
--On 22 January 2010 15:45:54 -0500 Edward Lewis wrote: contents) in example.org. So, whilst opt-out should be avoided across intervals containing secure delegations, I see no reason to avoid it across intervals that don't contain secure delegations. Opt-out is restricted to "intervals" that contain only unsecured delegations. Doh! Yes indeed. In which case I stand by my original argument: I can't see how opt-out really increase spoofability. It can't affect a secure delegation, and the contents of an insecure delegation or denial thereof (if not the delegation itself) are spoofable with or without opt-out. Paul's example of a secure delegation with opt-out across it can't exist. -- Alex Bligh ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
At 20:31 + 1/22/10, Alex Bligh wrote: contents) in example.org. So, whilst opt-out should be avoided across intervals containing secure delegations, I see no reason to avoid it across intervals that don't contain secure delegations. Opt-out is restricted to "intervals" that contain only unsecured delegations. RFC 5155: 6. Opt-Out ... (first paragraph's last sentence): name of the delegation. Setting the Opt-Out flag modifies this by allowing insecure delegations to exist within the signed zone without a corresponding NSEC3 RR at the hashed owner name of the delegation. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
Paul, --On 22 January 2010 14:51:38 -0500 Paul Wouters wrote: the NSEC3 RR chain. Therefor, Opt-Out should be avoided if possible. 1. Therefor*e* 2. I don't think the last sentence follows from the foregoing, in that this behaviour is desirable for the zone operator! (I know what you mean). 3. Aside from that, I don't think an injunction to avoid Opt-Out in these terms is sensible in a delegation only zone. In such a zone, I don't really see the additional security risk from opt out across insecure delegations, given if a spoof can be done, it can be done at the delegated zone level. If I secure example.org, and .org is signed, OPT-OUT might cause a spoofed exemple.org to not be caught by the user's validating resolver. Therefor, I do think opt-out should be avoided when possible. If I run .org, which is signed, but example.org is NOT signed (i.e. is an unsigned delegation), there seems to be little reason to avoid opt out across it. Whilst it might be harder to spoof the absence or existence of the delegation, I can still spoof the contents (or absence of contents) in example.org. So, whilst opt-out should be avoided across intervals containing secure delegations, I see no reason to avoid it across intervals that don't contain secure delegations. There are considerable operational advantages in Opt Out (zone size, cryptographic complexity etc.) I understand zone size, though I don't understand "cryptographic complexity". Having different "security values" attached to data within the same zone seems more complex to me, not less complex? I meant computational resource requirements resultant from crypto operations, not algorithmic complexity. The owner names in NSEC3 RRs are cryptographic hashes of the original owner name. Assume you have a delegation only zone consisting of sparse secure delegations amongst many insecure delegations. If you are using NSEC3 at all, using opt-out substantially reduces the number of NSEC3 records (since many insecure delegations will cluster together within the opt-out interval) and thus the length of the NSEC3 chain, and hence reduce the number of cryptographic hash calculations. Similarly the zone itself is smaller, so less work to sign. The situation is exacerbated where the insecure delegations are volatile. It might be worth mentioning (but is perhaps blindingly obvious) that NSEC3 is substantially more complex in terms of implementation than NSEC. Whilst one can by visual inspection spot the odd problem with a small zone's NSEC chain, it's far harder with NSEC3. Obviously, if a tool chain is used to NSECify and sign the zone, that's a problem for the implementor rather than the operator. -- Alex Bligh ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Fri, 22 Jan 2010, Alex Bligh wrote: completely ignores opt-out. How about Though all agree DNS data should be accessible through query mechanisms, a side effect of NSEC is that it allows the contents of a zone file to be enumerate in full by sequential query. Whilst for some operators this behaviour is acceptable or even desirable, for others it is undesirable for policy, regulatory or other reasons. This is the first reason for development of NSEC3. The second reason for the existence of NSEC3 is that NSEC requires a signature over every RR in the zonefile, thereby ensuring that any denial of existence is cryptographically signed. However, in a large zonefile containing many delegations very few of which are to signed zones, this may produce unacceptable additional overhead especially where insecure delegations are subject to frequent update (a typical example might be a TLD operator with few registrants using secure delegations). NSEC3 allows intervals between two such delegations to "Opt-out" in which case they may contain one more more insecure delegations, thus reducing the size and cryptographic complexity of the zone. Sounds good. the NSEC3 RR chain. Therefor, Opt-Out should be avoided if possible. 1. Therefor*e* 2. I don't think the last sentence follows from the foregoing, in that this behaviour is desirable for the zone operator! (I know what you mean). 3. Aside from that, I don't think an injunction to avoid Opt-Out in these terms is sensible in a delegation only zone. In such a zone, I don't really see the additional security risk from opt out across insecure delegations, given if a spoof can be done, it can be done at the delegated zone level. If I secure example.org, and .org is signed, OPT-OUT might cause a spoofed exemple.org to not be caught by the user's validating resolver. Therefor, I do think opt-out should be avoided when possible. There are considerable operational advantages in Opt Out (zone size, cryptographic complexity etc.) I understand zone size, though I don't understand "cryptographic complexity". Having different "security values" attached to data within the same zone seems more complex to me, not less complex? for large zones only sparsely populated with secure delegations, particularly where few queries have DO set anyway. I'd like to avoid circular adoption loop arguments :) Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
--On 22 January 2010 23:09:11 +1100 Mark Andrews wrote: Additionally NSEC3 provides no real benefit is highly structured zones like IP6.ARPA. It is relatively easy to enumerate a IP6.ARPA zone even if it is using NSEC3 by making use of the zone's structure. e164.arpa. is probably the poster child for this. -- Alex Bligh ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
--On 22 January 2010 12:04:07 +0100 Olaf Kolkman wrote: Strawman text said: Though some claim all data in the DNS should be considered public, it sometimes is considered to be more then private, but less then public data. That does not describe the problem well, in that (1) it is not the data that is somewhere between public and private, it is that the mechanisms of access to that data that change, and (2) it completely ignores opt-out. How about Though all agree DNS data should be accessible through query mechanisms, a side effect of NSEC is that it allows the contents of a zone file to be enumerate in full by sequential query. Whilst for some operators this behaviour is acceptable or even desirable, for others it is undesirable for policy, regulatory or other reasons. This is the first reason for development of NSEC3. The second reason for the existence of NSEC3 is that NSEC requires a signature over every RR in the zonefile, thereby ensuring that any denial of existence is cryptographically signed. However, in a large zonefile containing many delegations very few of which are to signed zones, this may produce unacceptable additional overhead especially where insecure delegations are subject to frequent update (a typical example might be a TLD operator with few registrants using secure delegations). NSEC3 allows intervals between two such delegations to "Opt-out" in which case they may contain one more more insecure delegations, thus reducing the size and cryptographic complexity of the zone. 5.3.4 Opt-out An Opt-Out NSEC3 RR does not assert the existence or non-existence of the insecure delegations that it may cover. This allows for the addition or removal of these delegations without recalculating or re- signing RRs in the NSEC3 RR chain. Therefor, Opt-Out should be avoided if possible. 1. Therefor*e* 2. I don't think the last sentence follows from the foregoing, in that this behaviour is desirable for the zone operator! (I know what you mean). 3. Aside from that, I don't think an injunction to avoid Opt-Out in these terms is sensible in a delegation only zone. In such a zone, I don't really see the additional security risk from opt out across insecure delegations, given if a spoof can be done, it can be done at the delegated zone level. There are considerable operational advantages in Opt Out (zone size, cryptographic complexity etc.) for large zones only sparsely populated with secure delegations, particularly where few queries have DO set anyway. -- Alex Bligh ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Jan 22, 2010, at 1:09 PM, Mark Andrews wrote: > > Additionally NSEC3 provides no real benefit is highly structured zones > like IP6.ARPA. It is relatively easy to enumerate a IP6.ARPA zone even > if it is using NSEC3 by making use of the zone's structure. ACK good point. Maybe we need a little more descriptive about the methodology how the structure can be explored. --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
Additionally NSEC3 provides no real benefit is highly structured zones like IP6.ARPA. It is relatively easy to enumerate a IP6.ARPA zone even if it is using NSEC3 by making use of the zone's structure. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] rfc4641bis: NSEC vs NSEC3.
On Jan 21, 2010, at 6:52 PM, Paul Wouters wrote: > On Thu, 21 Jan 2010, Olaf Kolkman wrote: > >> In trying to get a reasonable version 2 out of the door before Anaheim I am >> trying to identify and where possibly close open issues. >> >> As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has >> the open issues listed and a per issue highlight of their history. > > I still don't see any recommendations regarding NSEC vs NSEC3. I mailed you > some comments about two IETF's ago I believe. Do you still have that email, > or should I try to dig it out? That was oversight. In fact I need to close/re read the mail (and follow up thread) on your comments on the other topics. But for the benefit of opening discussion here is the relevant open issue (http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/NSEC-NSEC3) including your straw man text for the working group to comment on. --Olaf $Id: NSEC-NSEC3 36 2010-01-22 11:02:32Z olaf $ 20100122 NSEC-NSEC3 Paul Wouters Added: 22 jan 2010 Discussion missing about NSEC vs NSEC3 Parameters from: http://www.ietf.org/mail-archive/web/dnsop/current/msg07282.html Discussion: From: Paul Wouters Subject:Comments/Additions on I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt Date: April 28, 2009 12:23:21 AM GMT+02:00 To: Olaf Kolkman Cc: dnsop WG , namedropp...@ops.ietf.org WG I am furthermore missing a discussion on NSEC vs NSEC3 and NSEC3 parameters. I've tried to write something sensible that is included below, as a presumed section 5: 5 Next Record type There are currently two types of next records that are provide authenticated denial of existence of DNS data in a zone. - The NSEC (RFC 4034) record builds a linked list of sorted RRlabels with their record types in the zone. - The NSEC3 (RFC5 155) record builds a similar linked list, but uses hashes instead of the RRLabels. 5.1 Reasons for the existence of NSEC and NSEC3 The NSEC record requires no cryptographic operations aside from validating its associated signature record. It is human readable and can be used in manual queries to determin correct operation. The disadvantage is that it allows for "zone walking", where one can request all the entries of a zone by following the next RRlabel pointed to in each subsequent NSEC record. Though some claim all data in the DNS should be considered public, it sometimes is considered to be more then private, but less then public data. The NSEC3 record uses a hashing method of the requested RRlabel. To increase the workload required to guess entries in the zone, the number of hashing interations can be specified in the NSEC3 record. Additionally, a salt can be specified that also modifies the hashes. Note that NSEC3 does not give full protection against information leakage from the zone. 5.2 NSEC or NSEC3 For small zones that only contain contain records in the APEX and a few common (guessable) RRlabels such as "www" or "mail", NSEC3 provides no real additional security, and the use of NSEC is recommended to ease the work required by signers and validating resolvers. For large zones where there is an implication of "not readilly available" RRlabels, such as those where one has to sign an NDA before obtaining it, NSEC3 is recommended. 5.3 NSEC3 parameters The NSEC3 hashing includes the FQDN in its uncompressed form. This ensures brute force work done by an attacker for one (FQDN) RRlabel cannot be re-used for another (FQDN) RRlabel attack, as these entries are per definition unique. 5.3.1 NSEC3 Algorithm The NSEC3 algorithm is specified as a version of the DNSKEY algorithm. The current options are: Algorithm 6, DSA-NSEC3-SHA1 is an alias for algorithm 3, DSA. Algorithm 7, RSASHA1-NSEC3-SHA1 is an alias for algorithm 5, RSASHA1. The algorithm choice therefor depends solely on the DNSKEY algorithm picked. [Note that there is an issue here as well as mentioned in Section 3.4 regarding RSASSA-PKCS1-v1_5 vs RSASSA-PSS as well as no algorithm choice for SHA-256] 5.3.2 NSEC3 Iterations RFC-5155 describes the useful limits of iterations compared to RSA key size. These are 150 iterations for 1024 bit keys, 500 iterations for 2048 bit keys and 2,500 iterations for 4096 bit keys. Choosing 2/3rd of the maximum is deemed to be a sufficiently costly yet not excessive value. 5.3.3 NSEC3 Salt The salt with NSEC3 is not used to increase the work required by an attacker attacking multiple domains, but as a method to enable creating a new set of hash values if at some point that might be required. The salt is used as a "roll over". The FQDN RRlabel, which is part of the value that is hashed, already ensures that brute force work for one RRlabel can not be re-used to attack other RRlabel due to their uniquenes. Key rollovers limit the amount of time attackers can spend on attacking a certain key before it is retired. The salt serves the same purpose f
