< draft-vcelak-nsec5-02.txt   draft-vcelak-nsec5-03.txt >
Network Working Group J. Vcelak Network Working Group J. Vcelak
Internet-Draft CZ.NIC Internet-Draft CZ.NIC
Intended status: Standards Track S. Goldberg Intended status: Standards Track S. Goldberg
Expires: September 22, 2016 D. Papadopoulos Expires: March 23, 2017 D. Papadopoulos
Boston University Boston University
March 21, 2016 September 19, 2016
NSEC5, DNSSEC Authenticated Denial of Existence NSEC5, DNSSEC Authenticated Denial of Existence
draft-vcelak-nsec5-02 draft-vcelak-nsec5-03
Abstract Abstract
The Domain Name System Security (DNSSEC) Extensions introduced the The Domain Name System Security (DNSSEC) Extensions introduced the
NSEC resource record (RR) for authenticated denial of existence and NSEC resource record (RR) for authenticated denial of existence and
the NSEC3 for hashed authenticated denial of existence. The NSEC RR the NSEC3 for hashed authenticated denial of existence. The NSEC RR
allows for the entire zone contents to be enumerated if a server is allows for the entire zone contents to be enumerated if a server is
queried for carefully chosen domain names; N queries suffice to queried for carefully chosen domain names; N queries suffice to
enumerate a zone containing N names. The NSEC3 RR adds domain-name enumerate a zone containing N names. The NSEC3 RR adds domain-name
hashing, which makes the zone enumeration harder, but not impossible. hashing, which makes the zone enumeration harder, but not impossible.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2016. This Internet-Draft will expire on March 23, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5 2. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5
3. How NSEC5 Works . . . . . . . . . . . . . . . . . . . . . . . 6 3. How NSEC5 Works . . . . . . . . . . . . . . . . . . . . . . . 6
4. NSEC5 Algorithms . . . . . . . . . . . . . . . . . . . . . . 7 4. NSEC5 Algorithms . . . . . . . . . . . . . . . . . . . . . . 7
5. The NSEC5KEY Resource Record . . . . . . . . . . . . . . . . 8 5. The NSEC5KEY Resource Record . . . . . . . . . . . . . . . . 8
5.1. NSEC5KEY RDATA Wire Format . . . . . . . . . . . . . . . 8 5.1. NSEC5KEY RDATA Wire Format . . . . . . . . . . . . . . . 8
5.2. NSEC5KEY RDATA Presentation Format . . . . . . . . . . . 8 5.2. NSEC5KEY RDATA Presentation Format . . . . . . . . . . . 8
6. The NSEC5 Resource Record . . . . . . . . . . . . . . . . . . 8 6. The NSEC5 Resource Record . . . . . . . . . . . . . . . . . . 9
6.1. NSEC5 RDATA Wire Format . . . . . . . . . . . . . . . . . 9 6.1. NSEC5 RDATA Wire Format . . . . . . . . . . . . . . . . . 9
6.2. NSEC5 Flags Field . . . . . . . . . . . . . . . . . . . . 9 6.2. NSEC5 Flags Field . . . . . . . . . . . . . . . . . . . . 9
6.3. NSEC5 RDATA Presentation Format . . . . . . . . . . . . . 10 6.3. NSEC5 RDATA Presentation Format . . . . . . . . . . . . . 10
7. The NSEC5PROOF Resource Record . . . . . . . . . . . . . . . 10 7. The NSEC5PROOF Resource Record . . . . . . . . . . . . . . . 10
7.1. NSEC5PROOF RDATA Wire Format . . . . . . . . . . . . . . 10 7.1. NSEC5PROOF RDATA Wire Format . . . . . . . . . . . . . . 11
7.2. NSEC5PROOF RDATA Presentation Format . . . . . . . . . . 11 7.2. NSEC5PROOF RDATA Presentation Format . . . . . . . . . . 11
8. NSEC5 Proofs . . . . . . . . . . . . . . . . . . . . . . . . 11 8. NSEC5 Proofs . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Name Error Responses . . . . . . . . . . . . . . . . . . 11 8.1. Name Error Responses . . . . . . . . . . . . . . . . . . 12
8.2. No Data Responses . . . . . . . . . . . . . . . . . . . . 12 8.2. No Data Responses . . . . . . . . . . . . . . . . . . . . 12
8.2.1. No Data Response, Opt-Out Not In Effect . . . . . . . 12 8.2.1. No Data Response, Opt-Out Not In Effect . . . . . . . 12
8.2.2. No Data Response, Opt-Out In Effect . . . . . . . . . 13 8.2.2. No Data Response, Opt-Out In Effect . . . . . . . . . 13
8.3. Wildcard Responses . . . . . . . . . . . . . . . . . . . 13 8.3. Wildcard Responses . . . . . . . . . . . . . . . . . . . 13
8.4. Wildcard No Data Responses . . . . . . . . . . . . . . . 13 8.4. Wildcard No Data Responses . . . . . . . . . . . . . . . 14
9. Authoritative Server Considerations . . . . . . . . . . . . . 14 9. Authoritative Server Considerations . . . . . . . . . . . . . 14
9.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . 14
9.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . 15 9.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . 16
9.3. NSEC5KEY Rollover Mechanism . . . . . . . . . . . . . . . 16 9.3. NSEC5KEY Rollover Mechanism . . . . . . . . . . . . . . . 17
9.4. Secondary Servers . . . . . . . . . . . . . . . . . . . . 17 9.4. Secondary Servers . . . . . . . . . . . . . . . . . . . . 17
9.5. Zones Using Unknown Hash Algorithms . . . . . . . . . . . 17 9.5. Zones Using Unknown Hash Algorithms . . . . . . . . . . . 17
9.6. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 17 9.6. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 17
10. Resolver Considerations . . . . . . . . . . . . . . . . . . . 17 10. Resolver Considerations . . . . . . . . . . . . . . . . . . . 18
11. Validator Considerations . . . . . . . . . . . . . . . . . . 17 11. Validator Considerations . . . . . . . . . . . . . . . . . . 18
11.1. Validating Responses . . . . . . . . . . . . . . . . . . 18 11.1. Validating Responses . . . . . . . . . . . . . . . . . . 18
11.2. Validating Referrals to Unsigned Subzones . . . . . . . 19 11.2. Validating Referrals to Unsigned Subzones . . . . . . . 19
11.3. Responses With Unknown Hash Algorithms . . . . . . . . . 19 11.3. Responses With Unknown Hash Algorithms . . . . . . . . . 19
12. Special Considerations . . . . . . . . . . . . . . . . . . . 19 12. Special Considerations . . . . . . . . . . . . . . . . . . . 19
12.1. Transition Mechanism . . . . . . . . . . . . . . . . . . 19 12.1. Transition Mechanism . . . . . . . . . . . . . . . . . . 19
12.2. NSEC5 Private Keys . . . . . . . . . . . . . . . . . . . 19 12.2. NSEC5 Private Keys . . . . . . . . . . . . . . . . . . . 20
12.3. Domain Name Length Restrictions . . . . . . . . . . . . 20 12.3. Domain Name Length Restrictions . . . . . . . . . . . . 20
13. Performance Considerations . . . . . . . . . . . . . . . . . 20 13. Performance Considerations . . . . . . . . . . . . . . . . . 20
13.1. Performance of Cryptographic Operations . . . . . . . . 20 13.1. Performance of Cryptographic Operations . . . . . . . . 20
13.1.1. NSEC3 Hashing Performance . . . . . . . . . . . . . 20 13.1.1. NSEC3 Hashing Performance . . . . . . . . . . . . . 20
13.1.2. NSEC5 Hashing Performance . . . . . . . . . . . . . 21 13.1.2. NSEC5 Hashing Performance . . . . . . . . . . . . . 21
13.1.3. DNSSEC Signing Performance . . . . . . . . . . . . . 21 13.1.3. DNSSEC Signing Performance . . . . . . . . . . . . . 22
13.2. Authoritative Server Startup . . . . . . . . . . . . . . 22 13.2. Authoritative Server Startup . . . . . . . . . . . . . . 22
13.3. NSEC5 Answer Generating and Processing . . . . . . . . . 23 13.3. NSEC5 Answer Generating and Processing . . . . . . . . . 23
13.4. Response Lengths . . . . . . . . . . . . . . . . . . . . 23 13.4. Precomputed NSEC5PROOF Values . . . . . . . . . . . . . 24
13.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . 24 13.5. Response Lengths . . . . . . . . . . . . . . . . . . . . 24
14. Security Considerations . . . . . . . . . . . . . . . . . . . 25 13.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . 25
14.1. Zone Enumeration Attacks . . . . . . . . . . . . . . . . 25 14. Security Considerations . . . . . . . . . . . . . . . . . . . 26
14.2. Hash Collisions . . . . . . . . . . . . . . . . . . . . 25 14.1. Zone Enumeration Attacks . . . . . . . . . . . . . . . . 26
14.2. Hash Collisions . . . . . . . . . . . . . . . . . . . . 26
14.3. Compromise of the Private NSEC5 Key . . . . . . . . . . 26 14.3. Compromise of the Private NSEC5 Key . . . . . . . . . . 26
14.4. Key Length Considerations . . . . . . . . . . . . . . . 26 14.4. Key Length Considerations . . . . . . . . . . . . . . . 27
14.5. Transitioning to a New NSEC5 Algorithm . . . . . . . . . 26 14.5. Transitioning to a New NSEC5 Algorithm . . . . . . . . . 27
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
17.1. Normative References . . . . . . . . . . . . . . . . . . 28 17.1. Normative References . . . . . . . . . . . . . . . . . . 28
17.2. Informative References . . . . . . . . . . . . . . . . . 30 17.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. RSA Full Domain Hash Algorithm . . . . . . . . . . . 31 Appendix A. RSA Full Domain Hash Algorithm . . . . . . . . . . . 32
A.1. FDH signature . . . . . . . . . . . . . . . . . . . . . . 31 A.1. FDH signature . . . . . . . . . . . . . . . . . . . . . . 32
A.2. FDH verification . . . . . . . . . . . . . . . . . . . . 32 A.2. FDH verification . . . . . . . . . . . . . . . . . . . . 33
Appendix B. Elliptic Curve VRF . . . . . . . . . . . . . . . . . 32 Appendix B. Elliptic Curve VRF . . . . . . . . . . . . . . . . . 33
B.1. ECVRF Hash To Curve . . . . . . . . . . . . . . . . . . . 33 B.1. ECVRF Hash To Curve . . . . . . . . . . . . . . . . . . . 34
B.2. ECVRF Auxiliary Functions . . . . . . . . . . . . . . . . 34 B.2. ECVRF Auxiliary Functions . . . . . . . . . . . . . . . . 35
B.2.1. ECVRF Hash Points . . . . . . . . . . . . . . . . . . 34 B.2.1. ECVRF Hash Points . . . . . . . . . . . . . . . . . . 35
B.2.2. ECVRF Proof To Hash . . . . . . . . . . . . . . . . . 35 B.2.2. ECVRF Proof To Hash . . . . . . . . . . . . . . . . . 36
B.2.3. ECVRF Decode Proof . . . . . . . . . . . . . . . . . 35 B.2.3. ECVRF Decode Proof . . . . . . . . . . . . . . . . . 36
B.3. ECVRF Signing . . . . . . . . . . . . . . . . . . . . . . 36 B.3. ECVRF Signing . . . . . . . . . . . . . . . . . . . . . . 37
B.4. ECVRF Verification . . . . . . . . . . . . . . . . . . . 36 B.4. ECVRF Verification . . . . . . . . . . . . . . . . . . . 37
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 37 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 38
Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 38 Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
1.1. Rationale 1.1. Rationale
The DNS Security Extensions (DNSSEC) provides data integrity The DNS Security Extensions (DNSSEC) provides data integrity
protection using public-key cryptography, while not requiring that protection using public-key cryptography, while not requiring that
authoritative servers compute signatures on-the-fly. The content of authoritative servers compute signatures on-the-fly. The content of
the zone is usually pre-computed and served as is. The evident the zone is usually pre-computed and served as is. The evident
advantages of this approach are reduced performance requirements per advantages of this approach are reduced performance requirements per
skipping to change at page 22, line 43 skipping to change at page 22, line 48
handles the NSEC RRs the same way as any other records in the handles the NSEC RRs the same way as any other records in the
zone. zone.
NSEC3 The authoritative server can precompute NSEC3 hashes for all NSEC3 The authoritative server can precompute NSEC3 hashes for all
domain names in the NSEC3-signed zone on startup. With respect to domain names in the NSEC3-signed zone on startup. With respect to
query answering, this can speed up inclusion of NSEC3 RRs for query answering, this can speed up inclusion of NSEC3 RRs for
existing domain names (i.e., Closest provable encloser and QNAME existing domain names (i.e., Closest provable encloser and QNAME
for No Data response). for No Data response).
NSEC5 Very similar considerations apply for NSEC3 and NSEC5. There NSEC5 Very similar considerations apply for NSEC3 and NSEC5. There
is a strong motivation to precompute the NSEC5 proofs because they is a strong motivation to store the NSEC5PROOF values for existing
are costly to compute. A possible solution to reduce the startup domain names in order to reduce query processing time. A possible
time is to store the precomputed NSEC5 proofs and NSEC5 hashes in way to do this, without inceasing the zone size, is to store
a persistent storage. NSEC5PROOF values in a persistent storage structure, as explained
in Section 13.4.
The impact of NSEC3 and NSEC5 on the authoritative server startup The impact of NSEC3 and NSEC5 on the authoritative server startup
performance is greatly implementation specific. The server software performance is greatly implementation specific. The server software
vendor has to seek balance between answering performance, startup vendor has to seek balance between answering performance, startup
slowdown, and additional storage cost. slowdown, and additional storage cost.
13.3. NSEC5 Answer Generating and Processing 13.3. NSEC5 Answer Generating and Processing
An authenticated denial proof is required for No Data, Name Error, An authenticated denial proof is required for No Data, Name Error,
Wildcard Match, and Wildcard No Data answer. The number of required Wildcard Match, and Wildcard No Data answer. The number of required
skipping to change at page 23, line 33 skipping to change at page 23, line 38
The following list summarizes additional cryptographic operations The following list summarizes additional cryptographic operations
performed by the authoritative server for authenticated denial worst- performed by the authoritative server for authenticated denial worst-
case scenario: case scenario:
o NSEC: o NSEC:
* No cryptographic operations required. * No cryptographic operations required.
o NSEC3: o NSEC3:
* NSEC3 hash for Closest provable encloser (possibly precomputed) * NSEC3 hash for Closest provable encloser
* NSEC3 hash for Next closer name * NSEC3 hash for Next closer name
* NSEC3 hash for wildcard at the closest encloser * NSEC3 hash for wildcard at the closest encloser
o NSEC5: o NSEC5:
* NSEC5 proof and hash for Closest provable encloser (possibly * NSEC5 proof and hash for Closest provable encloser (possibly
precomputed) precomputed)
* NSEC5 proof and hash for Next closer name * NSEC5 proof and hash for Next closer name
13.4. Response Lengths 13.4. Precomputed NSEC5PROOF Values
As we dicussed in the previous section, the worst-case authenticated
denial scenario with NSEC5 entails the computation of two NSEC5 proof
and hash values, one for the Closest provable encloser and one for
the Next closer name. For the latter, these values must be computed
from scratch at query time. However, the proof value for the former
had been computed during startup, without being stored, as part of
the NSEC5 hash computation.
The query processing time can be drastically reduced if the NSEC5
proof values for all existing names in the zone are stored by the
authoritative. In that case, the authoritative identifies the
Closest provable encloser name for the given query and looks up both
the NSEC5 proof and hash value. This limits the necessary
computation during query processing to just one NSEC5 proof and hash
value (that of the Next closer name). For both variants of NSEC5,
the proof computation time strongly dominates the final NSEC5 hash
computation. Therefore, by storing NSEC5 proof values query
processing time is almost halved.
On the other hand, this slightly increases the used storage space at
the authoritative. It should be noted that these values should not
be part of the zone explicitly. They can be stored at an additional
data structure.
13.5. Response Lengths
[nsec5ecc] precisely measured response lengths for NSEC, NSEC3 and [nsec5ecc] precisely measured response lengths for NSEC, NSEC3 and
NSEC5 using empirical data from a sample second-level domain NSEC5 using empirical data from a sample second-level domain
containing about 1000 names. The sample zone was signed several containing about 1000 names. The sample zone was signed several
times with different DNSSEC signing algorithms and different times with different DNSSEC signing algorithms and different
authenticated denial of existence mechanisms. authenticated denial of existence mechanisms.
For DNSKEY algorithms, RSASHA256 (2048-bit) and ECDSAPSHA256 were For DNSKEY algorithms, RSASHA256 (2048-bit) and ECDSAPSHA256 were
considered. For authenticated denial, NSEC, NSEC3, NSEC5 with considered. For authenticated denial, NSEC, NSEC3, NSEC5 with
RSAFDH-SHA256-SHA256 (2048-bit), and NSEC5 with EC-P256-SHA256 were RSAFDH-SHA256-SHA256 (2048-bit), and NSEC5 with EC-P256-SHA256 were
skipping to change at page 24, line 28 skipping to change at page 25, line 17
| | algorithm | (octets) | (octets) | | | algorithm | (octets) | (octets) |
+-----------+--------------+------------------+---------------------+ +-----------+--------------+------------------+---------------------+
| NSEC | RSA | 1116 | 48 | | NSEC | RSA | 1116 | 48 |
| NSEC | ECDSA | 543 | 24 | | NSEC | ECDSA | 543 | 24 |
| NSEC3 | RSA | 1440 | 170 | | NSEC3 | RSA | 1440 | 170 |
| NSEC3 | ECDSA | 752 | 84 | | NSEC3 | ECDSA | 752 | 84 |
| NSEC5/RSA | RSA | 1767 | 7 | | NSEC5/RSA | RSA | 1767 | 7 |
| NSEC5/EC | ECDSA | 839 | 7 | | NSEC5/EC | ECDSA | 839 | 7 |
+-----------+--------------+------------------+---------------------+ +-----------+--------------+------------------+---------------------+
13.5. Summary 13.6. Summary
As anticipated, NSEC and NSEC3 are the most efficient authenticated As anticipated, NSEC and NSEC3 are the most efficient authenticated
denial mechanisms, in terms of computation for authoritative server denial mechanisms, in terms of computation for authoritative server
and resolver. NSEC also has the shortest response lengths. However, and resolver. NSEC also has the shortest response lengths. However,
these mechanisms do not prevent zone enumeration. these mechanisms do not prevent zone enumeration.
Regarding mechanisms that do prevent zone enumeration, NSEC5 should Regarding mechanisms that do prevent zone enumeration, NSEC5 should
be examined in contrast with Minimally Covering NSEC Records or NSEC3 be examined in contrast with Minimally Covering NSEC Records or NSEC3
White Lies [RFC7129]. The following table summarizes their White Lies [RFC7129]. The following table summarizes their
comparison in terms of response size, performance at the comparison in terms of response size, performance at the
skipping to change at page 38, line 5 skipping to change at page 38, line 48
00 - fix NSEC5KEY rollover mechanism, clarify NSEC5PROOF RDATA, 00 - fix NSEC5KEY rollover mechanism, clarify NSEC5PROOF RDATA,
clarify inputs and outputs for NSEC5 proof and NSEC5 hash clarify inputs and outputs for NSEC5 proof and NSEC5 hash
computation computation
01 - added Performance Considerations section 01 - added Performance Considerations section
02 - Elliptic Curve based VRF for NSEC5 proofs; response sizes 02 - Elliptic Curve based VRF for NSEC5 proofs; response sizes
based on empirical data based on empirical data
03 - Precomputed NSEC5PROOF Values (section Section 13.4)
Appendix D. Open Issues Appendix D. Open Issues
Note to RFC Editor: please remove this appendix before publication as Note to RFC Editor: please remove this appendix before publication as
an RFC. an RFC.
1. Consider alternative way to signalize NSEC5 support. The NSEC5 1. Consider alternative way to signalize NSEC5 support. The NSEC5
could use only one DNSSEC algorithm identifier, and the actual could use only one DNSSEC algorithm identifier, and the actual
algorithm to be used for signing can be the first octet in DNSKEY algorithm to be used for signing can be the first octet in DNSKEY
public key field and RRSIG signature field. Similar approach is public key field and RRSIG signature field. Similar approach is
used by PRIVATEDNS and PRIVATEOID defined in [RFC4034]. used by PRIVATEDNS and PRIVATEOID defined in [RFC4034].
 End of changes. 21 change blocks. 
43 lines changed or deleted 73 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/