140 likes | 251 Views
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
E N D
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 (NSEC3-PARAM), reuse NSEC3 at zone apex, special case the zone apex NSEC3. • Currently heavily leaning toward using NSEC3-PARAM
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?