Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

[Olaf Kolkman <[e-mail]>]

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 <[e-mail]> 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