NSEC3 Update

1
NSEC3 Update

• IETF 66, Montréal
• David Blacka, Verisign

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

3
What is going on?

• Workshop in Frankfurt on May 8-10
• Draft is now at version -06
• Side meeting this Monday
• Proposed next workshop

4
Frankfurt Workshop

• Purpose interoperability testing, discussion.
• Testing signing, serving, validation.
• No major issues found.
• But didnt test everything.
• Created a semi-permanent test environment
• Notes for the workshop
• http//www.nsec3.org/cgi-bin/trac.cgi/wiki/Works
  hop1Notes

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

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

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

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

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

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

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

12
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
  (NSEC3-PARAM), reuse NSEC3 at zone apex, special
  case the zone apex NSEC3.
• Currently heavily leaning toward using NSEC3-PARAM

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

14
Fin

• Questions/Comments?