1 / 14

NSEC3 Update from IETF 66: Progress, Issues, and Future Workshops

The NSEC3 protocol, an alternative to NSEC, aims to enhance DNS security by preventing zone enumeration through hashed domain names. Recent discussions at the IETF 66 in Montréal focused on ongoing development, interoperability testing, and unresolved issues, particularly concerning transitions between NSEC and NSEC3. Workshop details, including an upcoming Frankfurt meeting, highlight the importance of continued testing and collaboration. As the draft evolves (now at version -06), notable changes include enhanced signaling mechanisms and improved handling of unknown hash algorithms.

mele
Télécharger la présentation

NSEC3 Update from IETF 66: Progress, Issues, and Future Workshops

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 didn’t test everything. • Created a semi-permanent test environment • Notes for the workshop: http://www.nsec3.org/cgi-bin/trac.cgi/wiki/Workshop1Notes

  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?

More Related