On Jan 21, 2010, at 6:52 PM, Paul Wouters wrote: > On Thu, 21 Jan 2010, Olaf Kolkman wrote: > >> In trying to get a reasonable version 2 out of the door before Anaheim I am >> trying to identify and where possibly close open issues. >> >> As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has >> the open issues listed and a per issue highlight of their history. > > I still don't see any recommendations regarding NSEC vs NSEC3. I mailed you > some comments about two IETF's ago I believe. Do you still have that email, > or should I try to dig it out?
That was oversight. In fact I need to close/re read the mail (and follow up thread) on your comments on the other topics. But for the benefit of opening discussion here is the relevant open issue (http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/NSEC-NSEC3) including your straw man text for the working group to comment on. --Olaf $Id: NSEC-NSEC3 36 2010-01-22 11:02:32Z olaf $ 20100122 NSEC-NSEC3 Paul Wouters Added: 22 jan 2010 Discussion missing about NSEC vs NSEC3 Parameters from: http://www.ietf.org/mail-archive/web/dnsop/current/msg07282.html Discussion: From: Paul Wouters <p...@xelerance.com> Subject: Comments/Additions on I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt Date: April 28, 2009 12:23:21 AM GMT+02:00 To: Olaf Kolkman <o...@nlnetlabs.nl> Cc: dnsop WG <dnsop@ietf.org>, namedropp...@ops.ietf.org WG <namedropp...@ops.ietf.org> I am furthermore missing a discussion on NSEC vs NSEC3 and NSEC3 parameters. I've tried to write something sensible that is included below, as a presumed section 5: 5 Next Record type There are currently two types of next records that are provide authenticated denial of existence of DNS data in a zone. - The NSEC (RFC 4034) record builds a linked list of sorted RRlabels with their record types in the zone. - The NSEC3 (RFC5 155) record builds a similar linked list, but uses hashes instead of the RRLabels. 5.1 Reasons for the existence of NSEC and NSEC3 The NSEC record requires no cryptographic operations aside from validating its associated signature record. It is human readable and can be used in manual queries to determin correct operation. The disadvantage is that it allows for "zone walking", where one can request all the entries of a zone by following the next RRlabel pointed to in each subsequent NSEC record. Though some claim all data in the DNS should be considered public, it sometimes is considered to be more then private, but less then public data. The NSEC3 record uses a hashing method of the requested RRlabel. To increase the workload required to guess entries in the zone, the number of hashing interations can be specified in the NSEC3 record. Additionally, a salt can be specified that also modifies the hashes. Note that NSEC3 does not give full protection against information leakage from the zone. 5.2 NSEC or NSEC3 For small zones that only contain contain records in the APEX and a few common (guessable) RRlabels such as "www" or "mail", NSEC3 provides no real additional security, and the use of NSEC is recommended to ease the work required by signers and validating resolvers. For large zones where there is an implication of "not readilly available" RRlabels, such as those where one has to sign an NDA before obtaining it, NSEC3 is recommended. 5.3 NSEC3 parameters The NSEC3 hashing includes the FQDN in its uncompressed form. This ensures brute force work done by an attacker for one (FQDN) RRlabel cannot be re-used for another (FQDN) RRlabel attack, as these entries are per definition unique. 5.3.1 NSEC3 Algorithm The NSEC3 algorithm is specified as a version of the DNSKEY algorithm. The current options are: Algorithm 6, DSA-NSEC3-SHA1 is an alias for algorithm 3, DSA. Algorithm 7, RSASHA1-NSEC3-SHA1 is an alias for algorithm 5, RSASHA1. The algorithm choice therefor depends solely on the DNSKEY algorithm picked. [Note that there is an issue here as well as mentioned in Section 3.4 regarding RSASSA-PKCS1-v1_5 vs RSASSA-PSS as well as no algorithm choice for SHA-256] 5.3.2 NSEC3 Iterations RFC-5155 describes the useful limits of iterations compared to RSA key size. These are 150 iterations for 1024 bit keys, 500 iterations for 2048 bit keys and 2,500 iterations for 4096 bit keys. Choosing 2/3rd of the maximum is deemed to be a sufficiently costly yet not excessive value. 5.3.3 NSEC3 Salt The salt with NSEC3 is not used to increase the work required by an attacker attacking multiple domains, but as a method to enable creating a new set of hash values if at some point that might be required. The salt is used as a "roll over". The FQDN RRlabel, which is part of the value that is hashed, already ensures that brute force work for one RRlabel can not be re-used to attack other RRlabel due to their uniquenes. Key rollovers limit the amount of time attackers can spend on attacking a certain key before it is retired. The salt serves the same purpose 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. 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 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. A scenario where one of the authoratative nameservers of a zone does not have enough resources to hold the additional NSEC3 records in memory is one of very few reasons to deploy with Opt-Out. ________________________________________________________ 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
