NSEC3 Update
IETF 66, Montréal
David Blacka, Verisign
Review
• NSEC3 is an NSEC alternative that:
– Prevents zone enumeration by using
hashes of domain names
– Optional optimization for delegation centric
zones called Opt-Out.
What is going on?
•
•
•
•
Workshop in Frankfurt on May 8-10
Draft is now at version -06
Side meeting this Monday
Proposed next workshop
Frankfurt Workshop
•
•
•
•
•
•
Purpose: interoperability testing, discussion.
Testing signing, serving, validation.
No major issues found.
But didn’t test everything.
Created a semi-permanent test environment
Notes for the workshop:
http://www.nsec3.org/cgi-bin/trac.cgi/wiki/Workshop1Notes
Frankfurt Workshop, cont.
• Tests that still need to be done:
– NSEC to NSEC3 rollover, vice versa
– Signaling mechanism(s)
– Traversing down various combinations of
NSEC, NSEC3, with/without Opt-Out
– Spoof tests, esp. Wildcards + Opt-Out.
Changes from -05 to -06
•
•
•
•
•
Lots of wordsmithing.
Added hash length field to RDATA.
New section on signaling.
New section on dynamic update.
New text on handling unknown NSEC3
hash algorithms
• Updated examples.
Changes, cont.
• Responses are now required to use
NSEC3 with all the same parameters.
• A few things still missing:
– Text on transitioning a zone from NSEC to
NSEC3.
– Open issues.
Issues
• NSEC3 has an issue tracker
– http://www.nsec3.org
• Some issues are closed.
– This means that the draft editors think that
the issue is addressed.
– Not that the issue cannot be discussed
further.
Open Issues
• Issue 8: Signaling
– This is about interoperability with RFC
4035-based resolvers. I.e., NSEC3 signed
zones should be treated as insecure.
– At workshop, discussed two possibilities
– New draft describes the use of unknown
signing algorithms.
– Not set in stone, but that is what has been
implemented.
Open Issues, cont.
• Issue 9: Iterations upper bound
– Document sets an upper bound based on
RSA signing times, resolvers may treat
NSEC3 RRs with too many iterations as
BOGUS
– Should be based on verifications instead?
– Resolvers should treat as INSECURE
instead?
– How does upper bound change over time?
Open Issues, cont.
• Issue 11: Queries for NSEC3
ownernames
– 3 different approaches have been
suggested.
– All 3 have been described in past versions
of the draft.
– Main issue is if direct queries for NSEC3
RRs should work.
Open Issues, cont.
• Issue 18: Signaling complete NSEC3 chains.
– So auth servers (primary and secondary) can
determine the NSEC3 parameters
– Currently requires finding the NSEC3 for the zone
apex.
– 3 other proposals: new zone apex RR (NSEC3PARAM), reuse NSEC3 at zone apex, special
case the zone apex NSEC3.
– Currently heavily leaning toward using NSEC3PARAM
Open Issues, cont.
• Issue 22: Separating NSEC3 algorithms from
DS algorithms
– Currently re-uses the DS hash algorithm registry.
– But, desired hash properties are not (exactly) the
same.
– Do not necessarily want to define new NSEC3
hash when DS defines a new hash.
– Use of some hashes might require additional
specification.
Fin
Questions/Comments?