NSEC3 Status and Issues

1
NSEC3 Status and Issues

• IETF 65
• 21 March 2006
• Geoffrey Sisson
• Ben Laurie
• Roy Arends

2
Recent developments
NSEC3 Status

• 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/Worksho
  p0
• Principally intended to test basic functionality
  in tools
• Revealed subtle issues regarding handling of WCs
  / CEs

3
Recent Developments
NSEC3 Status

• 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-05pre
  1.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
Recent Developments (pt. 3)
NSEC3 Status

• 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
Closed Issues
NSEC3 Status

• 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
Closed Issues
NSEC3 Status

• 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
Closed Issues
NSEC3 Status

• 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 its 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
Closed Issues
NSEC3 Status

• 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
Closed Issues
NSEC3 Status

• NSEC3 Issue 5Hash 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
Closed Issues
NSEC3 Status

• 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
Closed Issues
NSEC3 Status

• 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
  gt 222 octets then NSEC rather than NSEC3 will
  have to be used.

12
Open Issues
NSEC3 Status

• 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 draftietf-dnsext-dnssec-
  experiments.

13
Open Issues
NSEC3 Status

• 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
Open Issues
NSEC3 Status

• 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
Open Issues
NSEC3 Status

• 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
Open Issues
NSEC3 Status

• 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
Open Issues
NSEC3 Status

• 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
Next steps
NSEC3 Status

• 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
Next steps
NSEC3 Status

• Questions or Comments?