Requirements related to DNSSEC Signed Proof of Non-Existence

Dom

ain

Nam

e Sy

stem

Se

curi

tyRequirements related to

DNSSEC Signed Proof of Non-Existence

draft-ietf-dnsext-signed-nonexistence-requirements-01.txt

Ben Laurie – NominetRip Loomis – SAIC

10 November 2004

2004-11-10 dnsext-signed-nonexistence-requirements-01 2

Dom

ain

Nam

e Sy

stem

Se

curi

tyDraft 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.


Dom

ain

Nam

e Sy

stem

Se

curi

tyTerminology

• “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.


Dom

ain

Nam

e Sy

stem

Se

curi

tyGroup 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]


Dom

ain

Nam

e Sy

stem

Se

curi

tyGroup 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.


Dom

ain

Nam

e Sy

stem

Se

curi

tyGroup 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.


Dom

ain

Nam

e Sy

stem

Se

curi

tyGroup 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.


Dom

ain

Nam

e Sy

stem

Se

curi

tyGroup 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…


Dom

ain

Nam

e Sy

stem

Se

curi

tyGroup 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


Dom

ain

Nam

e Sy

stem

Se

curi

tyGroup 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.


Dom

ain

Nam

e Sy

stem

Se

curi

tyGroup 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


Dom

ain

Nam

e Sy

stem

Se

curi

ty

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++.


Dom

ain

Nam

e Sy

stem

Se

curi

tyGroup 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.


Dom

ain

Nam

e Sy

stem

Se

curi

tyGroup 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.


Dom

ain

Nam

e Sy

stem

Se

curi

tyGroup 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.


Dom

ain

Nam

e Sy

stem

Se

curi

tyGroup 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.


Dom

ain

Nam

e Sy

stem

Se

curi

tyGroup 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.


Dom

ain

Nam

e Sy

stem

Se

curi

tyGroup 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


Dom

ain

Nam

e Sy

stem

Se

curi

tyGroup 15b – Universal Signing

• Newly identified requirement• “It should be possible to sign all zones with

NSEC++”• We rate this as “highly desirable”


Dom

ain

Nam

e Sy

stem

Se

curi

tyGroup 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


Dom

ain

Nam

e Sy

stem

Se

curi

tyGroup 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.


Dom

ain

Nam

e Sy

stem

Se

curi

tyPrioritization (1 of 2) -

RequirementsGr. Req'ts Nature Priority

13,4,5,6, 10,25

Zone enumeration and exposure Reqt - High

38,20,21, 22,23,24 Compatibility and transition Reqt - High

13 19 Replay Reqt - High

15a NEW Universal Signing Reqt - High

15c NEW Universal Signing Reqt - High


Dom

ain

Nam

e Sy

stem

Se

curi

tyPrioritization (2 of 2) – DesiresGr. Req'ts Nature Priority14 NEW Security during transition Desire - Med

15b NEW Universal Signing Desire - Med

16 NEW NSEC-only resolver results Desire - Med

5 11 Adoption and zone growth Desire - Med

11 17 Completeness Desire - Med

7 13 Exposure of signing keys Desire - Med

10 16 Complexity Desire - Med

12 18 DNS "purity" Desire - Med

8 14 Zone signing cost Desire - Med

9 15 DoS prevention Desire - Low

2 7 Zone size Desire - Low

4 9 Empty non-terminals Desire - Low

6 12 Non-overlap in namespace Desire - V. Low


Dom

ain

Nam

e Sy

stem

Se

curi

tyPrioritization 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…)


Dom

ain

Nam

e Sy

stem

Se

curi

tyOther 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


Dom

ain

Nam

e Sy

stem

Se

curi

tyThe 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.

Requirements related to DNSSEC Signed Proof of Non-Existence

Documents

Transcript of Requirements related to DNSSEC Signed Proof of Non-Existence