Requirements related to DNSSEC Signed Proof of Non-Existence

1
Requirements related to DNSSEC Signed Proof of
Non-Existence

• draft-ietf-dnsext-signed-nonexistence-requirements
  -01.txt
• Ben Laurie Nominet
• Rip Loomis SAIC
• 10 November 2004

2
Draft status

• Version -01 released Sept 2004
• No significant feedback received on- or off-list
  by the editors
• Informal discussions on 08 Nov AM (at IETF61)
  have provided possible clarifications, some
  potential new requirements
• and maybe a way ahead.

3
Terminology

• Current DNS DNS without DNSSEC cryptographic
  extensions, and with AXFR disabled for
  unauthorized entities
• DNSSECbis Self explanatory?
• NSEC - Whatever is added/changed in DNSSECbis
  to provide a new method of authenticatable
  non-existence. We know that some possible
  solutions will not actually be a new NSEC.
• DNSSEC-TNG A/K/A DNSSECter DNSSECbis plus the
  NSEC changes. We expect that DNSSECter will
  likely still include the current NSEC record as
  well.

4
Group 1 Zone enumeration and exposure

• Comprised of reqts 3, 4, 5, 6, 10, 26
• We suggest that these boil down to DNSSECter
  should not make it easier to enumerate zones than
  it is with plain DNS. Derived from reqt 4
• We believe that this is a high-priority
  requirement.
• Threshold requirement Enumeration is at least
  non-trivial (where current NSEC provides a
  linked list that is considered trivial to walk).
  Derived from reqt 3
• Concrete test might be that a random zone is
  infeasible to enumeratethis also reflects the
  goal requirement. Derived from reqt 5

5
Group 2 Zone size

• Comprised of reqt 7.
• We did not reword this requirement
• We believe that this is a nice to have desire,
  and not a true requirement.
• Comments welcomed as to how the zone size issue
  is in fact as significant as the other explicit
  requirements we received.
• Yes, it will receive some weighting in
  recommending a solution set.

6
Group 3 Compatibility and transition

• Comprised of reqts 8, 20, 21, 22, 23, 24
• We suggest that these boil down to Current
  deployment of DNSSECbis w/NSEC, by those who care
  not about zone enumeration, should not be
  affected by future NSEC deployment. Derived
  from reqts 20-24
• We believe that this is a high-priority
  requirement.
• Requirement 8 no longer applicable, because it
  would have mandated a change (that did not
  happen) to DNSSECbis.

7
Group 4 Empty non-terminals (ENT)

• Comprised of reqt 9.
• We did not reword this requirement.
• We believe that this is a low-priority desire.

8
Group 5 DNSSEC adoption and zone-growth

• Comprised of reqt 11
• We did not reword this requirement.
• We believe that this is a nice to have (medium
  priority desire)
• We are aware that consideration of this
  requirement may bog down the WG

9
Group 6 Non-overlap of denial records with
regular namespace

• Comprised of reqt 12
• We did not reword this requirement
• The editors are not sure that this has a
  realistic basisprotocols cannot protect against
  all possible foolish or silly actions.
• As usual, comments and clarifications welcome

10
Group 7 Online exposure of signing keys

• Comprised of reqt 13
• We did not reword this requirement
• We believe that this is a medium-priority desire
• It would be nice ifbut online keys may actually
  be an acceptable trade-off for a subset of those
  concerned with zone enumeration
• and it might not be an acceptable trade-off for
  others.

11
Group 8 Zone-signing cost

• Comprised of reqt 14
• We did not reword this requirement, but we added
  a 14a NSEC should not make incremental
  signing of existing zones any harder than it is
  with DNSSECbis/NSEC.
• We believe that this is a medium-priority desire

12
Group 9 DoS prevention/symmetric cost

• Comprised of reqt 15
• We reworded this as NSEC should not make
  Denial of Service attacks significantly more
  effective than plain DNSSECbis. Any increase in
  real-time cost at the name server (to respond)
  should correspond to a proportional increase in
  real-time cost to generate the original query.
• We believe that this is a low-priority desireit
  would be nice if, but in general DNSSEC makes
  DoS attacks so much easier that the answer is
  increasing available server CPU resources.
• Were also not sure that this is realistic given
  the other requirements for NSEC.

13
Group 10 Acceptable Complexity

• Comprised of reqt 16
• After further discussion, we rewrote this
  requirement as, Caching, wildcards, CNAMEs,
  DNAMEs should continue to work without
  significant increases in complexity at the client
  side.
• Complexity of operational usage
• Complexity of validator implementation
• We listed this as a medium priority desire.

14
Group 11 - Completeness

• Comprised of reqt 17
• What we think this was really supposed to
  require, after discussion with the original
  contributor there should not be a proof of
  non-existence for any valid data in the zone.
  This is much different than the requirement as
  expressed in I-D version -01, and essentially
  would prohibit an NSEC/NSEC that spans a range
  which contains valid data.
• Appears to conflict with requirement 11 (Group 5
  in this document). WG probably needs to resolve
  the conflict.
• Currently listed as a desire at the same
  priority as requirement 11.

15
Group 12 DNS purity

• Comprised of reqt 18
• After discussion with the contributor, the
  editors believe that this is really an awareness
  issue to be considered when reviewing potential
  solutions.
• For example, what if the hash of a name somehow
  collides with real data/RRs that are later
  added to a zone?
• This appears to be an implementation-side issue
  and not a going-in requirement that can be used
  to categorize potential solutions. For now, list
  as desirable.

16
Group 13 Replay

• Comprised of reqt 19
• DNSSECbis by design does not allow replay attacks
  that deny a record which already exists.
  However, attacks against a record which has been
  added will succeed (until the signature expires
  on the relevant NSEC)
• We reworded this requirement as NSEC should
  not allow replay attacks that are any more
  effective than those which currently exist in
  DNSSECbis.
• This is a requirement.

17
Group 14 Security During Zone Transition

• Newly identified requirement
• It should be possible to switch between NSEC and
  NSEC without any zone data appearing to be
  unsigned, insecure, or partly secure during the
  transition, taking into account externally cached
  data.
• We never want an end-user to see inconsistently
  signed data
• Both positive and negative answers should still
  be able to be validated
• This is at least highly desirable and perhaps a
  hard-and-fast requirement.

18
Group 15a Universal Signing

• Newly identified requirement
• Every zone that can be signed with DNSSECbis can
  also be signed with DNSSECter. (We believe that
  this is all zones, but do not want to prove it
  nor raise the bar for DNSSECter)
• Hard-and-fast requirement

19
Group 15b Universal Signing

• Newly identified requirement
• It should be possible to sign all zones with
  NSEC
• We rate this as highly desirable

20
Group 15c Universal Signing

• Newly identified requirement
• If it is not possible to sign all zones with
  NSEC it should be clearly defined which zones
  cannot be signed
• We believe this is a hard-and-fast requirement

21
Group 16 NSEC as seen by NSEC-only resolver

• Newly identified requirement
• An NSEC (only) zone, regardless of whether
  parent uses NSEC or NSEC, should appear as
  consistently unsigned when seen by an NSEC-only
  resolver.
• We never want an end-user to see inconsistently
  signed data
• This is at least highly desirable and perhaps a
  hard-and-fast requirement.

22
Prioritization (1 of 2) - Requirements
23
Prioritization (2 of 2) Desires
24
Prioritization Notes

• There are desired (but not required) features
  that some entities probably cannot live without
  (e.g., there are those who consider zone
  enumeration a security issue, but do not want to
  store keys online since they correctly view that
  as a potential security issue).
• The WG needs to ensure that the solution sets are
  reviewed appropriately and that any issues of
  this sort are identified. (We think this means
  that although no storage of keys online is not
  a hard-and-fast requirement for NSEC, its
  pretty close to one)

25
Other Notes

• Explicit non-requirement Prevent enumeration of
  RR types for a given name
• Even if it is notionally possible to provide this
  capability, we expect a steep cost and little
  benefit.
• Future provision of this capability is not
  prevented, if warranted

26
The way ahead?

• If the WG agrees with our summarizations, we will
  update the I-D to reflect this.
• Next step will be to consider potential solution
  sets against these requirements and desires, with
  appropriate weighting.