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 <o...@nlnetlabs.nl> 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop