Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

[Olaf Kolkman <[e-mail]>]

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.

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


Thanks!!!!

--Olaf

Dump... still work in progress


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.  Differences between  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 determine 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 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.

   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 iteration's 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 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.

   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 readily
   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 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 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 next record algorithm choice therefore 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

   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



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


   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

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



________________________________________________________ 

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