1 / 19

NSEC3 Status and Issues

NSEC3 Status and Issues. IETF 65 21 March 2006 Geoffrey Sisson Ben Laurie Roy Arends. NSEC3 Status. Recent developments. NSEC3 issues list was reviewed at IETF 64 in Vancouver Subsequently discussed on namedroppers Some were closed New issues were identified and added

joebennett
Télécharger la présentation

NSEC3 Status and Issues

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 Status and Issues IETF 65 21 March 2006 Geoffrey Sisson Ben Laurie Roy Arends

  2. NSEC3 Status Recent developments • NSEC3 issues list was reviewed at IETF 64 in Vancouver • Subsequently discussed on namedroppers • Some were closed • New issues were identified and added • Current list available at: http://www.nsec3.org/ • More about these shortly • A workshop has been scheduled for 8-10 May at DENIC in Frankfurt. • Intention is to fully test implementations and interoperability • A “pre-workshop” was held at Nominet on 6-8 March • http://www.nsec3.org/cgi-bin/trac.cgi/wiki/Workshop0 • Principally intended to test basic functionality in tools • Revealed subtle issues regarding handling of WCs / CEs

  3. NSEC3 Status Recent Developments • draft-ietf-dnsext-dnssec-nsec3-04 submitted on 6 March • draft-ietf-dnsext-dnssec-nsec3-05 to be submitted shortly • Preview draft available at: http://www.nsec3.org/draft-ietf-dnsext-nsec3-05pre1.txt • Significant changes from –03 to –04: • Ordering of base32 hashes changed to match canonical ordering • Hash function field changed to match DS digest registry • More text on NSEC3 validation • Recommendations for maximum number of iterations (based on signing cost) • Zone parameters are defined by parameters at SOA • Significant changes from –04 to –05pre1: • All known NSEC3 responses/validations enumerated • Clarifications arising from the pre-workshop

  4. NSEC3 Status Recent Developments (pt. 3) • Working code • NSD 2.3.3 • Patches by Ben Laurie • pdnssec-signzone • NSEC3 zone signer written in Perl by Roy Arends • jdnssec-signzone • NSEC3 zone signer written in Java by David Blacka • All available at http://www.nsec3.org/cgi-bin/trac.cgi/wiki/Implementations • Unbound • NSEC3 recursive validating resolver • NSEC3 branch, available from NSEC3 svn repository. • http://www.rfc.se/unbound • dig 9.3.2 • Patches by Ben Laurie • Understands NSEC3 typecode.

  5. NSEC3 Status Closed Issues NSEC3 Issue 1: Use of Hashes Creates New Owner Names Issue: • Signed zone that uses NSEC3 introduces new owner names that are Base32-encoded hashes of existing owner names in the zone Resolution: • Not a problem • Possible for an NSEC3 RR may have the same owner name as a real owner name; the consequences of this are considered in Issue 12

  6. NSEC3 Status Closed Issues NSEC3 Issue 2: RFC 3548 Base32 Sort Order Issue: • RFC 3548 describes a Base32 encoding that is unsuitable for NSEC3 hashes, as the sort order of the encodings differ from binary sort order. Resolution: • If rfc3548bis is published, the nsec3 draft will be changed to reference this encoding scheme; otherwise the draft will reference the one used in RFC 2938

  7. NSEC3 Status Closed Issues NSEC3 Issue 3: Determination of Correct Zone Parameters Issue: • How does a name server determine the correct parameters (algorithm, salt, iterations) for an NSEC3 zone? Discussion: • A name server has to be able to look up the NSEC3 RR associated with an owner name. To do this, it must have the correct values for the salt and number of iterations required to produce the hash value which is the owner name of the NSEC3 RR. However, an NSEC3 zone may contain any number of incomplete chains of NSEC3 RRs provided that at least one is complete. Consequently it cannot use the values contained in any arbitrary NSEC3 RR in the zone. Resolution: • If it’s a requirement an NSEC3 RR for the host name of the apex exists only if an (otherwise) complete chain of NSEC3 RRs with the same parameters exists, then a name server may obtain the correct values from any NSEC3 RRs that has the SOA bit set in the Bit Type field.

  8. NSEC3 Status Closed Issues NSEC3 Issue 4: Design Rationale Issue: • –03 needed to include more information about rationale underlying various design decisions, for example: • Why use a salt? • Why use iterations? Resolution: • An expanded design rationale was included in –04. This will be augmented in –05.

  9. NSEC3 Status Closed Issues NSEC3 Issue 5:Hash Function RDATA Too Short Issue: • The hash function field of the RDATA section of the NSEC3 RR is seven bits long; however RFC 4034 specifies that DNSSEC security algorithms are identified by 8-bit numbers Resolution: • This is fixed in –04. The high-bit of the Iterations field was “repurposed” as the opt-in bit.

  10. NSEC3 Status Closed Issues NSEC3 Issue 6: Owner names of hashes are limited to case-folded name Issue: • The owner names of NSEC3 RRs are currently restricted to case-folded names as non-case folded names will not be ordered properly in a zone. Base32 has been selected for this encoding. Consequently NSEC3 RRs require a 32 octet owner name to represent each hash, 12 more than the binary representation of the hash. Discussion: • Some have suggested that NSEC3 could use a new binary label type for owner names rather than Base32-encoded labels; would be a significant departure from previous IETF conservatism, e.g. the selection of ASCII encoding for IDNs. Would require broad, non-trivial modifications to existing implementations and, err, middleboxes. Resolution: • Base32-encoded labels will be used.

  11. NSEC3 Status Closed Issues NSEC3 Issue 7: Maximum Domain Name Length Issue: • The owner name of the apex of an NSEC3 zone is limited to 222 octets, as the NSEC3 hash for the apex (and any other owner names in the zone) is constrained to 255 octets. In practise, vanishingly few domain names approach this length. Resolution: • It's unlikely many domain names will be affected by this limitation – perhaps a few pathological cases. If DNSSEC is to be used for domain names > 222 octets then NSEC rather than NSEC3 will have to be used.

  12. NSEC3 Status Open Issues NSEC3 Issue 8: NSEC3 Signaling Mechanism Issue: • Should a name server for a DNSSEC zone that uses NSEC3 RRs only somehow signal this to NSEC3-unaware DNSSEC applications Discussion: • Several approaches have been discussed: • Full Type Code Rollover • Partial Type Code Rollover • Use a new DS message digest number • Use an unknown algorithm identifier in DS and RSIG RRs • Do Nothing Proposed Resolution: Approach four appears to be the most promising. It is well documented by draft–ietf-dnsext-dnssec-experiments.

  13. NSEC3 Status Open Issues NSEC3 Issue 9: Potential DoS on Resolvers Issue: • A potential DoS condition exists in which the operator of a malicious server could select an impractically high number of iterations for the NSEC3 RRs in an signed zone. Discussion: • One solution would be to permit resolvers to set an upper limit for the number of iterations that would be permitted in an NSEC3 RR, and to treat NSEC3 RRs with values exceeding this as insecure or bogus. This could be accomplished at the implementation level alone, or it could be governed by a recommendation or standard. Resolution: • We agree that it is desirable for resolvers to set an upper limit. We propose to submit the following two questions for consideration by the IETF Security Area Directorate: • Should an upper limit be specified in the standard? • If so, should the upper limit be specified in a separate document so that the it may be updated without having to re-publish the entire standard.

  14. NSEC3 Status Open Issues NSEC3 Issue 10: Potential DoS on Servers Issue: • Significantly more work is required for a name server to respond to queries which require negative proofs using NSEC3 than is required for a client to compose and send them. For each such query, the name server must repeatedly call the hash function for the number of iterations specified in the NSEC3 RRs. Consequently, name servers with NSEC3 zones are susceptible to asymmetric DoS attacks. Resolution: • None at present. • If name servers serving NSEC3 zones have highest-spec CPUs, it's possible that the rate of queries required to degrade server function could be made to be higher than that required to saturate the server's network connection(s). • Also, while not optimal, implementations could provide a reduced quality of service for queries which require negative proofs, so that resolution and validation of existing names will not be compromised.

  15. NSEC3 Status Open Issues NSEC3 Issue 11: Queries for NSEC3 RRs Issue: • What should be contained in responses to queries where the QNAME is the owner name of an existing NSEC3 RR and the QTYPE is not NSEC3 Resolution: • Return NOERROR/NODATA with non-existence proof and the NSEC3 RR at QNAME • (discussed in great detail on the issue tracker)

  16. NSEC3 Status Open Issues NSEC3 Issue 12: NSEC3 RR Owner Name Coincidence Issue: • It's possible for an NSEC3 RR and other RRs to have the same owner name in an NSEC3 zone. • Astronomically unlikely to happen as a coincidence • Possible by deliberate action, e.g. someone inserts a TXT RR with the same owner name as an existing NSEC3 RR • Say, die75kdbpq7tm7u8klq4kgoor752cqmd.example. TXT “foo” Resolution: • We believe that preventing NSEC3 RRs and another RRs from having the same owner name is a non-requirement, and that no special processing required when they do.

  17. NSEC3 Status Open Issues NSEC3 Issue 13: DDNS and Opt-In Determination Issue: • When a DDNS client sends an UPDATE transaction containing RRs for a new unsigned delegation to be inserted into an NSEC3 zone, there is no obvious way for the server to determine whether or not the new delegation should be included in the NSEC3 chain. Discussion: • Possible approaches: • No support for Opt-In in DDNS • Use overloaded NSEC3 RR to signal Opt-In • Introduce a new RRTYPE for used with DDNS update • Inherited behaviour • Discourage or prohibit partial Opt-In zones. Proposed Resolution: • None. We are still investigating the problem space.

  18. NSEC3 Status Next steps • Workshop has been scheduled for 8-10 May at DENIC in Frankfurt. • Intention is to fully tests implementations and interoperability • More info at: http://www.nsec3.org/ • -05 out soon.

  19. NSEC3 Status Next steps Questions or Comments?

More Related