1 / 26

Requirements related to DNSSEC Signed Proof of Non-Existence

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. Draft status. Version -01 released Sept 2004 No significant feedback received on- or off-list by the editors

carr
Download Presentation

Requirements related to DNSSEC Signed Proof of Non-Existence

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. 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. dnsext-signed-nonexistence-requirements-01

  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. dnsext-signed-nonexistence-requirements-01

  4. Group 1 – Zone enumeration and exposure • Comprised of req’ts 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 req’t 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 req’t 3] • Concrete test might be that a random zone is infeasible to enumerate—this also reflects the “goal requirement”. [Derived from req’t 5] dnsext-signed-nonexistence-requirements-01

  5. Group 2 – Zone size • Comprised of req’t 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. dnsext-signed-nonexistence-requirements-01

  6. Group 3 – Compatibility and transition • Comprised of req’ts 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 req’ts 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. dnsext-signed-nonexistence-requirements-01

  7. Group 4 – Empty non-terminals (ENT) • Comprised of req’t 9. • We did not reword this requirement. • We believe that this is a low-priority desire. dnsext-signed-nonexistence-requirements-01

  8. Group 5 – DNSSEC adoption and zone-growth • Comprised of req’t 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… dnsext-signed-nonexistence-requirements-01

  9. Group 6 – Non-overlap of denial records with “regular” namespace • Comprised of req’t 12 • We did not reword this requirement • The editors are not sure that this has a realistic basis—protocols cannot protect against all possible foolish or silly actions. • As usual, comments and clarifications welcome dnsext-signed-nonexistence-requirements-01

  10. Group 7 – Online exposure of signing keys • Comprised of req’t 13 • We did not reword this requirement • We believe that this is a medium-priority desire • It would be nice if…but 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. dnsext-signed-nonexistence-requirements-01

  11. Group 8 – Zone-signing cost • Comprised of req’t 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 dnsext-signed-nonexistence-requirements-01

  12. Group 9 – DoS prevention/symmetric cost • Comprised of req’t 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 desire—”it would be nice if”, but in general DNSSEC makes DoS attacks so much easier that the answer is increasing available server CPU resources. • We’re also not sure that this is realistic given the other requirements for NSEC++. dnsext-signed-nonexistence-requirements-01

  13. Group 10 – Acceptable Complexity • Comprised of req’t 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. dnsext-signed-nonexistence-requirements-01

  14. Group 11 - Completeness • Comprised of req’t 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. dnsext-signed-nonexistence-requirements-01

  15. Group 12 – DNS “purity” • Comprised of req’t 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. dnsext-signed-nonexistence-requirements-01

  16. Group 13 – Replay • Comprised of req’t 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. dnsext-signed-nonexistence-requirements-01

  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. dnsext-signed-nonexistence-requirements-01

  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 dnsext-signed-nonexistence-requirements-01

  19. Group 15b – Universal Signing • Newly identified requirement • “It should be possible to sign all zones with NSEC++” • We rate this as “highly desirable” dnsext-signed-nonexistence-requirements-01

  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 dnsext-signed-nonexistence-requirements-01

  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. dnsext-signed-nonexistence-requirements-01

  22. Prioritization (1 of 2) - Requirements dnsext-signed-nonexistence-requirements-01

  23. Prioritization (2 of 2) – Desires dnsext-signed-nonexistence-requirements-01

  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++, it’s pretty close to one…) dnsext-signed-nonexistence-requirements-01

  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 dnsext-signed-nonexistence-requirements-01

  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. dnsext-signed-nonexistence-requirements-01

More Related