draft-ietf-dnsext-nsec3-01

1
draft-ietf-dnsext-nsec3-01

• Ben Laurie
• Roy Arends
• DNSEXT_at_ 62nd IETF

2
Introduction

• Integrated the two proposals (NSEC2, DNSNR) into
  NSEC3.
• Switched from EXIST RR to additional NSEC3
  RRsets.
• Switched from hashed labels to hashed ownernames.
• Salt can now be of variable length.
• Iterations and opt-in retained.

3
Input from WG

• Sam needs extra text on changing salt.
• Requirement nsec3 requires a set of records that
  completely covers the zone, using a single salt
• Issue How to change salt?
• Resolution To a validator, NSEC3 is atomic, so
  salts may differ between NSEC3 records in a
  response.

4
Input from WG

• Changing iterations has the same issue and
  resolution as changing salts.

5
Input from WG

• Issue Cant roll hash value without protocol
  roll.
• Resolution mandate all algorithms.
• Question should we mandate a single algorithm
  (sha-???) and drop the alg. field?

6
Input from WG

• Issue What is the impact of hash collisions?
• Collisions between existing names can be
  resolved
• By changing salt or iteration when type bit maps
  are different. This has to be done for the entire
  zone.
• Hash collisions are highly unlikely in practice.

7
Input from WG

• Hash collisions between QNAME and exiting name.
• In this case, we cant prove non-existence of the
  QNAME.
• This looks bogus to the validator.
• No serious security consequence, since the name
  does not exist to begin with.
• Hash collisions are highly unlikely in practice.

8
Input from WG

• Issue Do we allow truncation.
• Long hashes lead to longer packets.
• Note signatures are much larger, so truncation
  has limited benefit.
• Truncation leads to higher collision probability.

9
Input from WG

• Mark A. separate the hash namespace. i.e. the
  ownername of NSEC3 appear to be in the root zone.
  The RDATA contains the zone name. This allows
  NSEC3 to apply to very VERY long owner names.
• Nice idea, but it has side issues we dont want
  to think about. (impact on root-servers, etc,
  etc).
• We are not planning to change the draft to
  incorporate this.
• Really long names can also be handled through
  DNAME.

10
Further work

• Non-existence proof
• 2 NSEC3s to prove closest encloser
• 1 shows closest encloser
• 1 shows non-existence of closer encloser
• One label longer than the closest encloser
• 1 NSEC3 to prove absence of wildcards
• The asterisk label plus the closest encloser.
• The validator algorithm is subtle, please read
  the draft.

11
Conclusion

• Last call ?