Subject: Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

From: Olaf Kolkman <[email-masked]>
Date: Wed, 17 Feb 2010 15:12:08 +0100

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 <[email-masked]> 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 & Gieben        Expires 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 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.

   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

   The first reason to deploy NSEC3, prevention of zone enumeration,
   makes sense when zone content is not highly structured or trivially
   guessable.  Highly structured zones zuch as the in-addr.arpa,
   ip6.arpa and e164.arpa can be trivially enumerated using ordinary DNS
   properties while for small zones that only contain contain records in
   the APEX and a few common RRlabels such as "www" or "mail" guessing
   zone content and proving completeness is also trivial when using
   NSEC3.

   In those cases 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.

   The considerations for the second reason to deploy NSEC3 are
   discussed below (Section 5.3.4).

Kolkman & Gieben        Expires September 8, 2009              [Page 32]
Internet-Draft   DNSSEC Operational Practices, Version 2      March 2009

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

   RFC5155 [24] considers the tradeoffs between incuring cost during the
   signing process, imposing costs to the validating nameserver, while
   still providing a reasonable barrier against dictionary attacks.  It
   provides 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 for the hashes, which are independant of the key being

Kolkman & Gieben        Expires 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.

5.3.4.  Opt-out

   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].  This allows for the
   addition or removal of the delegations covered by the span without
   recalculating or re- signing RRs in the NSEC3 RR chain.  Opt-Out is
   specified to be used only over delegation points and will therefore
   only bring relieve in zones with a large number of zones and where
   the number of secure delegations is small.  This consideration
   typically holds for large top-level-domains and similar zones, in
   most other circumstances Opt-Out should not be deployed.  Further
   considerations can be found in RFC5155 section 12.2 [24].

6.  [...]

________________________________________________________ 

Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140, 
http://www.nlnetlabs.nl/               1098 XG Amsterdam

---

From: Paul Wouters <[email-masked]>
Date: Wed, 17 Feb 2010 10:03:13 -0500 (EST)

>   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, thus reducing the size and cryptographic complexity of

"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.

>   makes sense when zone content is not highly structured or trivially

"only makes sense" ?

>   The NSEC3 hashing includes the FQDN in its uncompressed form.  This

"over its uncompressed form"? The hash does not 'include' it.

>   The algorithm choice therefor depends solely on the DNSKEY algorithm

"The next record algorithm choice therefor....." to make it less confusing?

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

And then:

   The FQDN RRlabel,

>   Key, as that process in itself already requires all RRSIG's to be

Should there be any explanation about the NSEC3PARAM record here?

>   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

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 17 Feb 2010 17:16:03 +0100

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

> here that there is a trade-of. Opt-out isn't all positive. It has a

I turned that into:
" at the expense of the abillity to cryptographically deny the existence of names in a specific span."

>>  makes sense when zone content is not highly structured or trivially

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.

> "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 ..."

> "The next record algorithm choice therefor....." to make it less confusing?

Ack

> I would throw this around.

<pun>
No, you would not, at least you didn't the first time around the initial text was yours 
</pun>
(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:

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.

>>  Key, as that process in itself already requires all RRSIG's to be

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.

> to realise that the span is over hashes, and not over "most domains that

I understand what you mean but how important is it to build this argument comprehensively? 

Thanks!!!!

--Olaf

Dump... still work in progress

5.  Next Record type

5.1.  Differences between  NSEC and NSEC3

   can be used in manual queries to determine correct operation.  The

   Though all agree DNS data is accessible through query mechanisms, a
   side effect of NSEC is that it allows the contents of a zone file to
   be enumerated in full by sequential queries.  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 difference between NSEC and NSEC3.

   The second difference between NSEC and 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 at the expense of the ability to cryptographically deny the
   existence of names in a specific span.

   number of hashing iteration's can be specified in the NSEC3 record.

5.2.  NSEC or NSEC3

   The first motivation to deploy NSEC3, prevention of zone enumeration,
   only makes sense when zone content is not highly structured or
   trivially guessable.  Highly structured zones such as the in-
   addr.arpa, ip6.arpa and e164.arpa can be trivially enumerated using
   ordinary DNS properties while for small zones that only contain
   contain records in the APEX and a few common RRlabels such as "www"
   or "mail" guessing zone content and proving completeness is also
   trivial when using NSEC3.

   For large zones where there is an implication of "not readily
   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 algorithm is performed on the Fully Qualified
   Domain Name (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 next record algorithm choice therefore depends solely on the
   DNSKEY algorithm picked.

5.3.2.  NSEC3 Iterations

   One of the concerns with NSEC3 is that bad actors could perform a
   pre-calculated dictionary attack in order to assess if certain domain
   names exist within the zones or not.  Two mechanisms are introduced
   in the NSEC3 specification to increase the costs of such dictionary
   attacks: Iterations and Salt.

   RFC5155 [24] considers the trade-offs between incuring cost during
   the signing process, imposing costs to the validating nameserver,
   while still providing a reasonable barrier against dictionary
   attacks.  It provides 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

   While the NSEC3 iterations parameter increases the cost of hashing a
   dictionary word, the NSEC3 salt reduces the lifetime for which that
   calculated hash can be used.  A change of the salt value by the zone
   owner would cause an attacker to lose all precalculated work for that

   zone.

   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 (e.g. in other domains) due to their uniqueness.

   The salt of all NSEC3 records in a zone needs to be the same.  Since
   changing the salt requires all the NSEC3 records to be regenerated,
   and thus requires generating new RRSIG's over these NSEC3 records, it
   is recommended to align the change of the salt with a change of the
   Zone Signing Key, as that process in itself already requires all
   RRSIG's to be regenerated.  If there is no critical dependency on
   incremental signing and the whole zone can be signed with little
   effort there is no need for such alignment.

5.3.4.  Opt-out

---

From: Paul Wouters <[email-masked]>
Date: Wed, 17 Feb 2010 11:37:59 -0500 (EST)

> 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 probabl…

Ok.

> " at the expense of the abillity to cryptographically deny the existence of names in a specific span."

Ok.

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

> How about "hashing algorithm is performed on the FQDN ..."

Works for me.

> (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 :)

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

> 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

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 17 Feb 2010 17:59:25 +0100

>> How about "hashing algorithm is performed on the FQDN ..."

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

---

From: Alex Bligh <[email-masked]>
Date: Wed, 17 Feb 2010 23:22:39 +0000

>>   makes sense when zone content is not highly structured or trivially

How about "applies"

> "The next record algorithm choice therefor....." to make it less

"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)

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

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sat, 20 Feb 2010 08:37:16 -0500

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

>        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

---

From: Alex Bligh <[email-masked]>
Date: Sat, 20 Feb 2010 16:15:50 +0000

--On 20 February 2010 08:37:16 -0500 Olafur Gudmundsson <[email-masked]> 
wrote:

> 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

---

From: Paul Wouters <[email-masked]>
Date: Sat, 20 Feb 2010 11:48:59 -0500 (EST)

On Sat, 20 Feb 2010, Alex Bligh wrote:

> existence of the NSECx record).

If you can proof one, you can also proof the other :)

> I think they both only provide

That I agree with. NSEC3 plus OPT-OUT does not give a full
authenticated proof of non-existance.

Paul

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 20 Feb 2010 15:27:52 -0500

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:

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

> 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
[email-masked]
Shinkuro, Inc.

---

From: Evan Hunt <[email-masked]>
Date: Sat, 20 Feb 2010 21:31:33 +0000

> Some suggested changes below.

Same here.

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

> 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 -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sat, 20 Feb 2010 19:26:40 -0500

Thanks Evan and Andrew fot translating my thoughts into better prose.
Evan, you captures my meaning.

	Olafur

---

From: Todd Glassey <[email-masked]>
Date: Sun, 21 Feb 2010 09:31:15 -0800

>> 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
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> 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
>
>

---

From: John Dickinson <[email-masked]>
Date: Sun, 21 Feb 2010 18:16:21 +0000

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

---

From: Mark Andrews <[email-masked]>
Date: Mon, 22 Feb 2010 11:22:03 +1100

In message <[email-masked]>, 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: [email-masked]

---

From: Roy Arends <[email-masked]>
Date: Sun, 21 Feb 2010 22:53:12 -0500

On Feb 21, 2010, at 7:22 PM, Mark Andrews wrote:

>  NSEC3
> are hashed.

Are you going on again about the possibility of hash collisions is SHA-1? 

Roy

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 21 Feb 2010 20:13:28 -0800

> 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

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 22 Feb 2010 10:44:09 +0100

> 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

---

From: Roy Arends <[email-masked]>
Date: Mon, 22 Feb 2010 08:14:25 -0500

On Feb 22, 2010, at 4:44 AM, W.C.A. Wijngaards wrote:

> 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

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.

> larger packets when using NSEC3.  And opt-out, obfuscation desiderata.

All FUD.

Roy

---

From: Roy Arends <[email-masked]>
Date: Mon, 22 Feb 2010 08:16:49 -0500

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

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 22 Feb 2010 14:41:19 +0100

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

---

From: Alex Bligh <[email-masked]>
Date: Mon, 22 Feb 2010 14:41:46 +0000

--On 22 February 2010 14:41:19 +0100 "W.C.A. Wijngaards" 
<[email-masked]> wrote:

> I am not saying this makes NSEC3 a unchoosable option; but it

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

---

From: Evan Hunt <[email-masked]>
Date: Mon, 22 Feb 2010 16:12:51 +0000

> should also point out the whole of DNSSEC is predicated on similar

+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.

---

From: Matt Larson <[email-masked]>
Date: Mon, 22 Feb 2010 11:17:59 -0500

> 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

---

From: Edward Lewis <[email-masked]>
Date: Mon, 22 Feb 2010 10:31:12 -0600

>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
NeuStar                    You 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.

---

From: Roy Arends <[email-masked]>
Date: Mon, 22 Feb 2010 11:52:07 -0500

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 Feb 2010 09:05:47 -0800

> 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

---

From: Evan Hunt <[email-masked]>
Date: Mon, 22 Feb 2010 17:23:25 +0000

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

---

From: Todd Glassey <[email-masked]>
Date: Mon, 22 Feb 2010 09:41:38 -0800

--- SNIP ---

> 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

> Version: 8.5.435 / Virus Database: 271.1.1/2703 - Release Date: 02/22/10 07:34:00
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 Feb 2010 09:46:15 -0800

> 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

---

From: Roy Arends <[email-masked]>
Date: Mon, 22 Feb 2010 12:59:45 -0500

> 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

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 22 Feb 2010 13:51:57 -0500

On Mon, Feb 22, 2010 at 11:17:59AM -0500, Matt Larson wrote:

>   I am adamantly opposed to including

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
[email-masked]
Shinkuro, Inc.

---

From: Alex Bligh <[email-masked]>
Date: Mon, 22 Feb 2010 19:06:38 +0000

--On 22 February 2010 09:05:47 -0800 Eric Rescorla <[email-masked]> wrote:

>>> Alex Bligh wrote:
>>>> seem sensible ... And it isn't sensible to suggest
>>> +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.
>>
>> occuring
>> ...
>> Drunk Sysadmins, Rouge Registrar, etc, etc.
>>
> 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

---

From: Evan Hunt <[email-masked]>
Date: Mon, 22 Feb 2010 19:59:38 +0000

>   "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.)

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 Feb 2010 12:33:06 -0800

> 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

---

From: Edward Lewis <[email-masked]>
Date: Mon, 22 Feb 2010 14:48:29 -0600

At 19:59 +0000 2/22/10, Evan Hunt wrote:
>(But this conversation has already taken more time than the probability
>of a random collision really merits, so whatever.)

Yes, let's move on. (see http://en.wikipedia.org/wiki/Jumping_the_shark)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 22 Feb 2010 22:29:50 +0100

> any text about SHA1 hash collisions in an NSEC3 context.

+1.

	jakob

---

From: Mark Andrews <[email-masked]>
Date: Tue, 23 Feb 2010 10:41:28 +1100

> We'll claim that sha-1 is broken, write a paper on it and have our 15 minutes

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
> 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. :-)

---

From: Mark Andrews <[email-masked]>
Date: Tue, 23 Feb 2010 11:06:50 +1100

In message <[email-masked]>, 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.
> 

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.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 23 Feb 2010 11:13:04 +1100

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 23 Feb 2010 11:24:02 +1100

In message <[email-masked]>, Eric R
> into the category of "basic assumptions"

Basic assumptions should be noted.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 Feb 2010 16:29:32 -0800

> Basic assumptions should be noted.

Should we also note the Heisenberg uncertainty principle? general relativity?
The law of the excluded middle?

-Ekr

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 22 Feb 2010 20:08:53 -0500

On 2010-02-22, at 19:13, Mark Andrews <[email-masked]> 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
<[email-masked]>

---

From: Roy Arends <[email-masked]>
Date: Mon, 22 Feb 2010 20:50:15 -0500

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

> 1 in 32^32/(3*10^7) (1/48716721244363430606789494423876100655197)

I agree, approximately, a probability of 1 in 2^135.

> 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

---

From: Roy Arends <[email-masked]>
Date: Mon, 22 Feb 2010 20:55:53 -0500

> 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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 23 Feb 2010 14:42:20 +1100

In message <[email-masked]>, Roy Arends writes:
> >> The real problem is that a SHA1 hash collision would render all > signatures wi
> 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.

> >> I suggest that if you and Andrews want to have this claim rfc4641bis, > you sho
> >>> with a new salt, and also keep that 2-second update guarantee? - I > would
> >> the probability of finding a bug in authoritative server software is > way high
> See > https://www.isc.org/community/blog/201002/surprise-bugs-and-release-schedu> les
> 
> Roy-- 
Mark Andrews, ISC

---

From: Alex Bligh <[email-masked]>
Date: Tue, 23 Feb 2010 04:39:04 +0000

> 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

---

From: Doug Barton <[email-masked]>
Date: Mon, 22 Feb 2010 20:46:46 -0800

> Note that RFC 5155 takes the time to put the issue to rest not once but

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/

---

From: Doug Barton <[email-masked]>
Date: Mon, 22 Feb 2010 20:49:53 -0800

> 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

--

---

From: Florian Weimer <[email-masked]>
Date: Tue, 23 Feb 2010 07:20:16 +0000

>    Key, as that process in itself already requires all RRSIG's to be

"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                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Florian Weimer <[email-masked]>
Date: Tue, 23 Feb 2010 07:33:50 +0000

> 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).

---

From: Olaf Kolkman <[email-masked]>
Date: Tue, 23 Feb 2010 11:03:42 +0100

> each time the zone is updated."

ACK

> 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

---

From: Todd Glassey <[email-masked]>
Date: Tue, 23 Feb 2010 06:26:10 -0800

> 5155 (which seems to handle the issue well) is probably the right
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
> Version: 8.5.435 / Virus Database: 271.1.1/2704 - Release Date: 02/22/10 19:34:00
>
>

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Feb 2010 10:22:09 -0500 (EST)

On Tue, 23 Feb 2010, Florian Weimer wrote:

> DO=0 queries,

Wouldn't that be an implementation bug?

Paul

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 23 Feb 2010 07:27:00 -0800

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.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Feb 2010 10:40:46 -0500 (EST)

> 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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Feb 2010 10:42:50 -0500 (EST)

> 5155 (which seems to handle the issue well) is probably the right

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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Feb 2010 12:54:16 -0500 (EST)

> 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

---

From: Evan Hunt <[email-masked]>
Date: Tue, 23 Feb 2010 19:03:11 +0000

> Wouldn't that be an implementation bug?

Not if it was an ANY query.  Otherwise, yes.

---

From: Roy Arends <[email-masked]>
Date: Tue, 23 Feb 2010 14:08:05 -0500

> Not if it was an ANY query.  Otherwise, yes.

Or an NSEC query.

Roy

---

From: Roy Arends <[email-masked]>
Date: Tue, 23 Feb 2010 15:52:58 -0500

> 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

---

From: Doug Barton <[email-masked]>
Date: Tue, 23 Feb 2010 13:30:57 -0800

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

--

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Feb 2010 16:40:43 -0500 (EST)

> 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

---

From: Doug Barton <[email-masked]>
Date: Tue, 23 Feb 2010 19:31:39 -0800

> 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

--