< draft-vcelak-nsec5-01.txt   draft-vcelak-nsec5-02.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: March 24, 2016 Boston University Expires: September 22, 2016 D. Papadopoulos
September 21, 2015 Boston University
March 21, 2016
NSEC5, DNSSEC Authenticated Denial of Existence NSEC5, DNSSEC Authenticated Denial of Existence
draft-vcelak-nsec5-01 draft-vcelak-nsec5-02
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 41 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 March 24, 2016. This Internet-Draft will expire on September 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5 2. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5
3. How NSEC5 Works . . . . . . . . . . . . . . . . . . . . . . . 5 3. How NSEC5 Works . . . . . . . . . . . . . . . . . . . . . . . 6
4. NSEC5 Algorithms . . . . . . . . . . . . . . . . . . . . . . 6 4. NSEC5 Algorithms . . . . . . . . . . . . . . . . . . . . . . 7
5. The NSEC5KEY Resource Record . . . . . . . . . . . . . . . . 7 5. The NSEC5KEY Resource Record . . . . . . . . . . . . . . . . 8
5.1. NSEC5KEY RDATA Wire Format . . . . . . . . . . . . . . . 7 5.1. NSEC5KEY RDATA Wire Format . . . . . . . . . . . . . . . 8
5.2. NSEC5KEY RDATA Presentation Format . . . . . . . . . . . 7 5.2. NSEC5KEY RDATA Presentation Format . . . . . . . . . . . 8
6. The NSEC5 Resource Record . . . . . . . . . . . . . . . . . . 7 6. The NSEC5 Resource Record . . . . . . . . . . . . . . . . . . 8
6.1. NSEC5 RDATA Wire Format . . . . . . . . . . . . . . . . . 7 6.1. NSEC5 RDATA Wire Format . . . . . . . . . . . . . . . . . 9
6.2. NSEC5 Flags Field . . . . . . . . . . . . . . . . . . . . 8 6.2. NSEC5 Flags Field . . . . . . . . . . . . . . . . . . . . 9
6.3. NSEC5 RDATA Presentation Format . . . . . . . . . . . . . 9 6.3. NSEC5 RDATA Presentation Format . . . . . . . . . . . . . 10
7. The NSEC5PROOF Resource Record . . . . . . . . . . . . . . . 9 7. The NSEC5PROOF Resource Record . . . . . . . . . . . . . . . 10
7.1. NSEC5PROOF RDATA Wire Format . . . . . . . . . . . . . . 9 7.1. NSEC5PROOF RDATA Wire Format . . . . . . . . . . . . . . 10
7.2. NSEC5PROOF RDATA Presentation Format . . . . . . . . . . 10 7.2. NSEC5PROOF RDATA Presentation Format . . . . . . . . . . 11
8. NSEC5 Proofs . . . . . . . . . . . . . . . . . . . . . . . . 10 8. NSEC5 Proofs . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Name Error Responses . . . . . . . . . . . . . . . . . . 10 8.1. Name Error Responses . . . . . . . . . . . . . . . . . . 11
8.2. No Data Responses . . . . . . . . . . . . . . . . . . . . 11 8.2. No Data Responses . . . . . . . . . . . . . . . . . . . . 12
8.2.1. No Data Response, Opt-Out Not In Effect . . . . . . . 11 8.2.1. No Data Response, Opt-Out Not In Effect . . . . . . . 12
8.2.2. No Data Response, Opt-Out In Effect . . . . . . . . . 12 8.2.2. No Data Response, Opt-Out In Effect . . . . . . . . . 13
8.3. Wildcard Responses . . . . . . . . . . . . . . . . . . . 12 8.3. Wildcard Responses . . . . . . . . . . . . . . . . . . . 13
8.4. Wildcard No Data Responses . . . . . . . . . . . . . . . 12 8.4. Wildcard No Data Responses . . . . . . . . . . . . . . . 13
9. Authoritative Server Considerations . . . . . . . . . . . . . 13 9. Authoritative Server Considerations . . . . . . . . . . . . . 14
9.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . 14
9.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . 14 9.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . 15
9.3. NSEC5KEY Rollover Mechanism . . . . . . . . . . . . . . . 15 9.3. NSEC5KEY Rollover Mechanism . . . . . . . . . . . . . . . 16
9.4. Secondary Servers . . . . . . . . . . . . . . . . . . . . 16 9.4. Secondary Servers . . . . . . . . . . . . . . . . . . . . 17
9.5. Zones Using Unknown Hash Algorithms . . . . . . . . . . . 16 9.5. Zones Using Unknown Hash Algorithms . . . . . . . . . . . 17
9.6. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 16 9.6. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 17
10. Resolver Considerations . . . . . . . . . . . . . . . . . . . 16 10. Resolver Considerations . . . . . . . . . . . . . . . . . . . 17
11. Validator Considerations . . . . . . . . . . . . . . . . . . 16 11. Validator Considerations . . . . . . . . . . . . . . . . . . 17
11.1. Validating Responses . . . . . . . . . . . . . . . . . . 16 11.1. Validating Responses . . . . . . . . . . . . . . . . . . 18
11.2. Validating Referrals to Unsigned Subzones . . . . . . . 17 11.2. Validating Referrals to Unsigned Subzones . . . . . . . 19
11.3. Responses With Unknown Hash Algorithms . . . . . . . . . 17 11.3. Responses With Unknown Hash Algorithms . . . . . . . . . 19
12. Special Considerations . . . . . . . . . . . . . . . . . . . 18
12.1. Transition Mechanism . . . . . . . . . . . . . . . . . . 18 12. Special Considerations . . . . . . . . . . . . . . . . . . . 19
12.2. NSEC5 Private Keys . . . . . . . . . . . . . . . . . . . 18 12.1. Transition Mechanism . . . . . . . . . . . . . . . . . . 19
12.3. Domain Name Length Restrictions . . . . . . . . . . . . 18 12.2. NSEC5 Private Keys . . . . . . . . . . . . . . . . . . . 19
13. Performance Considerations . . . . . . . . . . . . . . . . . 19 12.3. Domain Name Length Restrictions . . . . . . . . . . . . 20
13.1. Performance of Cryptographic Operations . . . . . . . . 19 13. Performance Considerations . . . . . . . . . . . . . . . . . 20
13.2. Authoritative Server Startup . . . . . . . . . . . . . . 20 13.1. Performance of Cryptographic Operations . . . . . . . . 20
13.3. NSEC5 Answer Generating and Processing . . . . . . . . . 21 13.1.1. NSEC3 Hashing Performance . . . . . . . . . . . . . 20
14. Security Considerations . . . . . . . . . . . . . . . . . . . 24 13.1.2. NSEC5 Hashing Performance . . . . . . . . . . . . . 21
14.1. Zone Enumeration Attacks . . . . . . . . . . . . . . . . 24 13.1.3. DNSSEC Signing Performance . . . . . . . . . . . . . 21
14.2. Hash Collisions . . . . . . . . . . . . . . . . . . . . 24 13.2. Authoritative Server Startup . . . . . . . . . . . . . . 22
14.3. Compromise of the Private NSEC5 Key . . . . . . . . . . 24 13.3. NSEC5 Answer Generating and Processing . . . . . . . . . 23
14.4. Key Length Considerations . . . . . . . . . . . . . . . 25 13.4. Response Lengths . . . . . . . . . . . . . . . . . . . . 23
14.5. Transitioning to a New NSEC5 Algorithm . . . . . . . . . 25 13.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . 24
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 14. Security Considerations . . . . . . . . . . . . . . . . . . . 25
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 14.1. Zone Enumeration Attacks . . . . . . . . . . . . . . . . 25
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 14.2. Hash Collisions . . . . . . . . . . . . . . . . . . . . 25
17.1. Normative References . . . . . . . . . . . . . . . . . . 26 14.3. Compromise of the Private NSEC5 Key . . . . . . . . . . 26
17.2. Informative References . . . . . . . . . . . . . . . . . 27 14.4. Key Length Considerations . . . . . . . . . . . . . . . 26
Appendix A. Full Domain Hash Algorithm . . . . . . . . . . . . . 28 14.5. Transitioning to a New NSEC5 Algorithm . . . . . . . . . 26
A.1. FDH signature . . . . . . . . . . . . . . . . . . . . . . 28 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
A.2. FDH verification . . . . . . . . . . . . . . . . . . . . 29 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 29 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 30 17.1. Normative References . . . . . . . . . . . . . . . . . . 28
17.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. RSA Full Domain Hash Algorithm . . . . . . . . . . . 31
A.1. FDH signature . . . . . . . . . . . . . . . . . . . . . . 31
A.2. FDH verification . . . . . . . . . . . . . . . . . . . . 32
Appendix B. Elliptic Curve VRF . . . . . . . . . . . . . . . . . 32
B.1. ECVRF Hash To Curve . . . . . . . . . . . . . . . . . . . 33
B.2. ECVRF Auxiliary Functions . . . . . . . . . . . . . . . . 34
B.2.1. ECVRF Hash Points . . . . . . . . . . . . . . . . . . 34
B.2.2. ECVRF Proof To Hash . . . . . . . . . . . . . . . . . 35
B.2.3. ECVRF Decode Proof . . . . . . . . . . . . . . . . . 35
B.3. ECVRF Signing . . . . . . . . . . . . . . . . . . . . . . 36
B.4. ECVRF Verification . . . . . . . . . . . . . . . . . . . 36
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 37
Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
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
query, as well as not requiring private zone-signing keys to be query, as well as not requiring private zone-signing keys to be
present on nameservers facing the network. present on nameservers facing the network.
With DNSSEC, each resource record (RR) set in the zone is signed. With DNSSEC, each resource record (RR) set in the zone is signed.
The signature is retained as an RRSIG RR directly in the zone. This The signature is retained as an RRSIG RR directly in the zone. This
enables response authentication for data existing in the zone. To enables response authentication for data existing in the zone. To
ensure integrity of denying answers, an NSEC chain of all existing ensure integrity of denying answers, an NSEC chain of all existing
domain names in the zone is constructed. The chain is made of RRs, domain names in the zone is constructed. The chain is made of RRs,
where each RR represents two consecutive domain names in canonical where each RR represents two consecutive domain names in canonical
order present in the zone. The NSEC RRs are signed the same way as order present in the zone. The NSEC RRs are signed the same way as
any other RRs in the zone, and each NSEC can be used to prove that a any other RRs in the zone. Non-existence of a name can be thus
given name does not existing in a part of the domain name space. proven by presenting a NSEC RR which covers the name.
As side-effect, however, the NSEC chain allows for enumeration of the As side-effect, however, the NSEC chain allows for enumeration of the
zone's contents by sequentially querying for the names immediately zone's contents by sequentially querying for the names immediately
following those in the most-recently retrieved NSEC record; N queries following those in the most-recently retrieved NSEC record; N queries
suffice to enumerate a zone containing N names. As such, the NSEC3 suffice to enumerate a zone containing N names. As such, the NSEC3
hashed denial of existence was introduced to prevent zone hashed denial of existence was introduced to prevent zone
enumeration. In NSEC3, the original domain names in the NSEC chain enumeration. In NSEC3, the original domain names in the NSEC chain
are replaced by their cryptographic hashes. While NSEC3 makes zone are replaced by their cryptographic hashes. While NSEC3 makes zone
enumeration more difficult, offline dictionary attacks are still enumeration more difficult, offline dictionary attacks are still
possible and have been demonstrated; this is because hashes may be possible and have been demonstrated; this is because hashes may be
computed offline and the space of possible domain names is restricted computed offline and the space of possible domain names is restricted
[nsec3walker][nsec3gpu]. [nsec3walker][nsec3gpu].
Zone enumeration can be prevented with NSEC3 if having the Zone enumeration can be prevented with NSEC3 if having the
authoritative server compute NSEC3 RRs on-the-fly, in response to authoritative server compute NSEC3 RRs on-the-fly, in response to
queries with denying responses. Usually, this is done with Minimally queries with denying responses. Usually, this is done with Minimally
Covering NSEC Records or NSEC3 White Lies [RFC7129]. One of the most Covering NSEC Records or NSEC3 White Lies [RFC7129]. The
significant disadvantage of this approach is a required presence of disadvantage of this approach is a required presence of the private
the private key on all authoritative servers for the zone. This is key on all authoritative servers for the zone. This is often
often undesirable, as the holder of the private key can tamper with undesirable, as the holder of the private key can tamper with the
the zone content, and having private keys on many network-facing zone contents, and having private keys on many network-facing servers
servers increases the risk that keys can be compromised. increases the risk that keys can be compromised.
To prevent zone content enumeration without keeping private keys on To prevent zone content enumeration without keeping private keys on
all authoritative servers, NSEC5 replaces the unkeyed cryptographic all authoritative servers, NSEC5 replaces the unkeyed cryptographic
hash function used in NSEC3 with a public-key hashing scheme. hash function used in NSEC3 with a public-key hashing scheme.
Hashing in NSEC5 is performed with a separate NSEC5 key. The public Hashing in NSEC5 is performed with a separate NSEC5 key. The public
portion of this key is distributed in an NSEC5KEY RR, and is used to portion of this key is distributed in an NSEC5KEY RR, and is used to
validate NSEC5 hash values. The private portion of the NSEC5 key is validate NSEC5 hash values. The private portion of the NSEC5 key is
present on all authoritative servers for the zone, and is used to present on all authoritative servers for the zone, and is used to
compute hash values. compute hash values.
Importantly, the NSEC5KEY key cannot be used to modify the contents Importantly, the NSEC5KEY key cannot be used to modify the contents
of the zone. Thus, any compromise of the private NSEC5 key does not of the zone. Thus, any compromise of the private NSEC5 key does not
lead to a compromise of zone contents; all that is lost is privacy lead to a compromise of zone contents. All that is lost is privacy
against zone enumeration, effectively downgrading the security of against zone enumeration, effectively downgrading the security of
NSEC5 to that of NSEC3. NSEC5 comes with a cryptographic proof of NSEC5 to that of NSEC3. NSEC5 comes with a cryptographic proof of
security, available in [nsec5]. security, available in [nsec5].
The NSEC5 is not intended to replace NSEC or NSEC3. It is designed The NSEC5 is not intended to replace NSEC or NSEC3. It is designed
as an alternative mechanism for authenticated denial of existence. as an alternative mechanism for authenticated denial of existence.
1.2. Requirements 1.2. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 5, line 49 skipping to change at page 6, line 16
insecure. insecure.
The new algorithm identifiers defined by this document are listed in The new algorithm identifiers defined by this document are listed in
Section 15. Section 15.
3. How NSEC5 Works 3. How NSEC5 Works
To prove non-existence of a domain name in a zone, NSEC uses a chain To prove non-existence of a domain name in a zone, NSEC uses a chain
built from domain names present in the zone. NSEC3 replaces the built from domain names present in the zone. NSEC3 replaces the
original domain names by their cryptographic hashes. NSEC5 is very original domain names by their cryptographic hashes. NSEC5 is very
similar to NSEC3, however a public-key based hashing scheme is used. similar to NSEC3, except that the cryptographic hash is replaced by
hashes computed using a verifiable random function (VRF). A VRF is
essentially the public-key version of a keyed cryptographic hash. A
VRF comes with a public/private key pair, and only the holder of the
private key can compute the hash, but anyone with public key can
verify the hash.
In NSEC5, the original domain name is hashed twice: In NSEC5, the original domain name is hashed twice:
1. First, the domain name is hashed using the NSEC5 private key; the 1. First, the domain name is hashed using a VRF keyed with the NSEC5
result is called the NSEC5 proof. Only an authoritative server private key; the result is called the NSEC5 proof. Only an
that knows the private NSEC5 key can compute the NSEC5 proof. authoritative server that knows the private NSEC5 key can compute
Any client that knows the public NSEC5 key can validate the NSEC5 the NSEC5 proof. Any client that knows the public NSEC5 key can
proof. validate the NSEC5 proof.
2. Second, the NSEC5 proof is hashed using a cryptographic hash 2. Second, the NSEC5 proof is hashed. The result is called the
function; the result is called the NSEC5 hash. This hash can be NSEC5 hash value. This hash can be computed by any party that
computed by any party that knows the input NSEC5 proof. knows the input NSEC5 proof.
The NSEC5 hash determines the position of a domain name in an NSEC5 The NSEC5 hash determines the position of a domain name in an NSEC5
chain. That is, all the NSEC5 hashes for a zone are sorted in their chain. That is, all the NSEC5 hashes for a zone are sorted in their
canonical order, and each consecutive pair forms an NSEC5 RR. canonical order, and each consecutive pair forms an NSEC5 RR.
To prove an non-existence of a particular domain name in response to To prove an non-existence of a particular domain name in response to
a query, the server computes on the fly, the NSEC5 proof (using the a query, the server computes the NSEC5 proof (using the private NSEC5
private NSEC5 key). Then it uses the NSEC5 proof to compute the key) on the fly. Then it uses the NSEC5 proof to compute the
corresponding NSEC5 hash. It then identifies the NSEC5 RR that corresponding NSEC5 hash. It then identifies the NSEC5 RR that
covers the hash. In the response message, the server returns the covers the NSEC5 hash. In the response message, the server returns
NSEC5 RR, it's corresponding signature (RRSIG RRset), and synthesized the NSEC5 RR, it's corresponding signature (RRSIG RRset), and
NSEC5PROOF RR containing the NSEC5 proof it computed on the fly. synthesized NSEC5PROOF RR containing the NSEC5 proof it computed on
the fly.
To validate the response, the client first uses the public NSEC5 key To validate the response, the client first uses the public NSEC5 key
(stored in the zone as an NSEC5KEY RR) to verify that the NSEC5 proof (stored in the zone as an NSEC5KEY RR) to verify that the NSEC5 proof
corresponds with the domain name to be disproved. Then, the client corresponds with the domain name to be disproved. Then, the client
computes the NSEC5 hash from the NSEC5 proof and checks if the NSEC5 computes the NSEC5 hash from the NSEC5 proof and checks that it is
RR content and it's signature are valid. covered by the NSEC5 RR. Finally, it checks that the signature on
the NSEC5 RR is valid.
4. NSEC5 Algorithms 4. NSEC5 Algorithms
The algorithms used for NSEC5 authenticated denial are independent of The algorithms used for NSEC5 authenticated denial are independent of
the algorithms used for DNSSEC signing. An NSEC5 algorithm defines the algorithms used for DNSSEC signing. An NSEC5 algorithm defines
how the NSEC5 proof and the NSEC5 hash is computed and validated. how the NSEC5 proof and the NSEC5 hash is computed and validated.
The input for the NSEC5 proof computation is an RR owner name in the The input for the NSEC5 proof computation is an RR owner name in the
canonical form in the wire format and an NSEC5 private key; the canonical form in the wire format and an NSEC5 private key; the
output is an octet string. output is an octet string.
The input for the NSEC5 hash computation is the corresponding NSEC5 The input for the NSEC5 hash computation is the corresponding NSEC5
proof; the output is an octet string. proof; the output is an octet string.
This document defines FDH-SHA256-SHA256 NSEC5 algorithm as follows: This document defines RSAFDH-SHA256-SHA256 NSEC5 algorithm as
follows:
o NSEC5 proof is an RSA based Full Domain Hash (FDH) with SHA-256 o NSEC5 proof is computed using an RSA based Full Domain Hash (FDH)
hash function used internally for input preprocessing. The FDH signature with SHA-256 hash function used internally for input
signature and verification is formally specified in Appendix A. preprocessing. The signature and verification is formally
specified in Appendix A.
o NSEC5 hash is an SHA-256 hash function as specified in [RFC6234]. o NSEC5 hash is computed by hashing the NSEC5 proof with the SHA-256
hash function as specified in [RFC6234].
o The public key format to be used in NSEC5KEY RR is defined in o The public key format to be used in NSEC5KEY RR is defined in
Section 2 of [RFC3110] and thus is the same as the format used to Section 2 of [RFC3110] and thus is the same as the format used to
store RSA public keys in DNSKEY RRs. store RSA public keys in DNSKEY RRs.
The NSEC5 algorithm identifier for FDH-SHA256-SHA256 is 1. This document defines EC-P256-SHA256 NSEC5 algorithm as follows:
o NSEC5 proof is computed using an Elliptic Curve VRF with FIPS
186-3 P-256 curve. The proof computation and verification is
formally specified in Appendix B. The curve parameters are
specified in [FIPS-186-3] (Section D.1.2.3) and [RFC5114]
(Section 2.6).
o NSEC5 hash is x-coordinate of the group element gamma from the
NSEC5 proof (specified in Appendix B), encoded as a fixed-width
32-octet unsigned integer in network byte order. In practice, the
hash is a substring of the proof ranging from 2nd to 33th octet of
the proof inclusive.
o The public key format to be used in NSEC5KEY RR is defined in
Section 4 of [RFC6605] and thus is the same as the format used to
store ECDSA public keys in DNSKEY RRs.
This document defines EC-ED25519-SHA256 NSEC5 as follows:
o NSEC5 proof is the same as with EC-P256-SHA256 but using Ed25519
elliptic curve with parameters defined in [RFC7748] (Section 4.1).
o NSEC5 hash is the same as with EC-P256-SHA256.
o The public key format to be used in NSEC5KEY RR is defined in
Section 3 of [I-D.ietf-curdle-dnskey-ed25519] and thus is the same
as the format used to store Ed25519 public keys in DNSKEY RRs.
5. The NSEC5KEY Resource Record 5. The NSEC5KEY Resource Record
The NSEC5KEY RR stores an NSEC5 public key. The key allows clients The NSEC5KEY RR stores an NSEC5 public key. The key allows clients
to verify a validity of NSEC5 proof sent by a server. to verify a validity of NSEC5 proof sent by a server.
5.1. NSEC5KEY RDATA Wire Format 5.1. NSEC5KEY RDATA Wire Format
The RDATA for NSEC5KEY RR is as shown below: The RDATA for NSEC5KEY RR is as shown below:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Public Key / | Algorithm | Public Key /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Algorithm is a single octet identifying NSEC5 algorithm. Algorithm is a single octet identifying NSEC5 algorithm.
Public Key is a variable sized field holding public key material for Public Key is a variable sized field holding public key material for
NSEC5 proof verification. NSEC5 proof verification.
5.2. NSEC5KEY RDATA Presentation Format 5.2. NSEC5KEY RDATA Presentation Format
The presentation format of the NSEC5KEY RDATA is as follows: The presentation format of the NSEC5KEY RDATA is as follows:
skipping to change at page 8, line 5 skipping to change at page 9, line 9
The NSEC5 RR provides authenticated denial of existence for an RRset. The NSEC5 RR provides authenticated denial of existence for an RRset.
One NSEC5 RR represents one piece of an NSEC5 chain, proving One NSEC5 RR represents one piece of an NSEC5 chain, proving
existence of RR types present at the original domain name and also existence of RR types present at the original domain name and also
non-existence of other domain names in a part of the hashed domain non-existence of other domain names in a part of the hashed domain
name space. name space.
6.1. NSEC5 RDATA Wire Format 6.1. NSEC5 RDATA Wire Format
The RDATA for NSEC5 RR is as shown below: The RDATA for NSEC5 RR is as shown below:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | Flags | Next Length | | Key Tag | Flags | Next Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hashed Owner Name / | Next Hashed Owner Name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Type Bit Maps / / Type Bit Maps /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key Tag field contains the key tag value of the NSEC5KEY RR that Key Tag field contains the key tag value of the NSEC5KEY RR that
validates the NSEC5 RR, in network byte order. The value is computed validates the NSEC5 RR, in network byte order. The value is computed
from the NSEC5KEY RDATA using the same algorithm, which is used to from the NSEC5KEY RDATA using the same algorithm, which is used to
compute key tag values for DNSKEY RRs. The algorithm is defined in compute key tag values for DNSKEY RRs. The algorithm is defined in
[RFC4034]. [RFC4034].
Flags field is a single octet. The meaning of individual bits of the Flags field is a single octet. The meaning of individual bits of the
field is defined in Section 6.2. field is defined in Section 6.2.
skipping to change at page 8, line 39 skipping to change at page 9, line 43
Type Bit Maps is a variable sized field encoding RR types present at Type Bit Maps is a variable sized field encoding RR types present at
the original owner name matching the NSEC5 RR. The format of the the original owner name matching the NSEC5 RR. The format of the
field is equivalent to the format used in NSEC3 RR, described in field is equivalent to the format used in NSEC3 RR, described in
[RFC5155]. [RFC5155].
6.2. NSEC5 Flags Field 6.2. NSEC5 Flags Field
The following one-bit NSEC5 flags are defined: The following one-bit NSEC5 flags are defined:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| |W|O| | |W|O|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
O - Opt-Out flag O - Opt-Out flag
W - Wildcard flag W - Wildcard flag
All the other flags are reserved for future use and MUST be zero. All the other flags are reserved for future use and MUST be zero.
The Opt-Out flag has the same semantics as in NSEC3. The definition The Opt-Out flag has the same semantics as in NSEC3. The definition
and considerations in [RFC5155] are valid, except that NSEC3 is and considerations in [RFC5155] are valid, except that NSEC3 is
replaced by NSEC5. replaced by NSEC5.
skipping to change at page 9, line 43 skipping to change at page 10, line 43
7. The NSEC5PROOF Resource Record 7. The NSEC5PROOF Resource Record
The NSEC5PROOF record is synthesized by the authoritative server on- The NSEC5PROOF record is synthesized by the authoritative server on-
the-fly. The record contains the NSEC5 proof, proving a position of the-fly. The record contains the NSEC5 proof, proving a position of
the owner name in an NSEC5 chain. the owner name in an NSEC5 chain.
7.1. NSEC5PROOF RDATA Wire Format 7.1. NSEC5PROOF RDATA Wire Format
The RDATA for NSEC5PROOF is as as shown below: The RDATA for NSEC5PROOF is as as shown below:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | Owner Name Hash / | Key Tag | Owner Name Hash /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key Tag field contains the key tag value of the NSEC5KEY RR that Key Tag field contains the key tag value of the NSEC5KEY RR that
validates the NSEC5PROOF RR, in network byte order. validates the NSEC5PROOF RR, in network byte order.
Owner Name Hash is a variable sized sequence of binary octets Owner Name Hash is a variable sized sequence of binary octets
encoding the NSEC5 proof of the owner name of the RR. encoding the NSEC5 proof of the owner name of the RR.
7.2. NSEC5PROOF RDATA Presentation Format 7.2. NSEC5PROOF RDATA Presentation Format
The presentation format of the NSEC5PROOF RDATA is as follows: The presentation format of the NSEC5PROOF RDATA is as follows:
skipping to change at page 10, line 34 skipping to change at page 11, line 34
client that the response content is valid. client that the response content is valid.
2. Authoritative server proofs. NSEC5 RRs an authoritative server 2. Authoritative server proofs. NSEC5 RRs an authoritative server
must include in a response to prove the listed facts. must include in a response to prove the listed facts.
3. Validator checks. Individual checks a validating server is 3. Validator checks. Individual checks a validating server is
required to perform on a response. The response content is required to perform on a response. The response content is
considered valid only if all the checks pass. considered valid only if all the checks pass.
If NSEC5 is said to match a domain name, the owner name of the NSEC5 If NSEC5 is said to match a domain name, the owner name of the NSEC5
has to be equivalent to an NSEC5 hash of that domain name. If NSEC5 RR has to be equivalent to an NSEC5 hash of that domain name. If an
is said to cover a domain name, the NSEC5 hash of that name must lay NSEC5 RR is said to cover a domain name, the NSEC5 hash of the domain
strictly between the NSEC5 owner name and the NSEC5 Next Hashed Owner name must lay strictly between that NSEC5 RR's Owner Name and Next
Name. Hashed Owner Name.
8.1. Name Error Responses 8.1. Name Error Responses
Facts to prove: Facts to prove:
No RRset matching the QNAME exactly exists. No RRset matching the QNAME exactly exists.
No RRset matching the QNAME via wildcard expansion exists. No RRset matching the QNAME via wildcard expansion exists.
The QNAME does not fall into a delegation. The QNAME does not fall into a delegation.
skipping to change at page 14, line 5 skipping to change at page 15, line 5
1. Select an algorithm for NSEC5. Generate the public and private 1. Select an algorithm for NSEC5. Generate the public and private
NSEC5 keys. NSEC5 keys.
2. Add a NSEC5KEY RR into the zone apex containing the public NSEC5 2. Add a NSEC5KEY RR into the zone apex containing the public NSEC5
key. key.
3. For each unique original domain name in the zone and each empty 3. For each unique original domain name in the zone and each empty
non-terminal, add an NSEC5 RR. If Opt-Out is used, owner names non-terminal, add an NSEC5 RR. If Opt-Out is used, owner names
of unsigned delegations MAY be excluded. of unsigned delegations MAY be excluded.
a. The owner name of the NSEC5 RR is the NSEC5 hash of the A. The owner name of the NSEC5 RR is the NSEC5 hash of the
original owner name encoded in Base32hex without padding, original owner name encoded in Base32hex without padding,
prepended as a single label to the zone name. prepended as a single label to the zone name.
b. Set the Key Tag field to be the key tag corresponding to the B. Set the Key Tag field to be the key tag corresponding to the
public NSEC5 key. public NSEC5 key.
c. Clear the Flags field. If Opt-Out is being used, set the C. Clear the Flags field. If Opt-Out is being used, set the
Opt-Out flag. If there is a wildcard label directly Opt-Out flag. If there is a wildcard label directly
descending from the original domain name, set the Wildcard descending from the original domain name, set the Wildcard
flag. Note that the wildcard can be an empty non-terminal flag. Note that the wildcard can be an empty non-terminal
(i.e., the wildcard synthesis does not take effect and (i.e., the wildcard synthesis does not take effect and
therefore the flag is not to be set). therefore the flag is not to be set).
d. Set the Next Length field to a value determined by the used D. Set the Next Length field to a value determined by the used
NSEC5 algorithm. Leave the Next Hashed Owner Name field NSEC5 algorithm. Leave the Next Hashed Owner Name field
blank. blank.
e. Set the Type Bit Maps field based on the RRsets present at E. Set the Type Bit Maps field based on the RRsets present at
the original owner name. the original owner name.
4. Sort the set of NSEC5 RRs into canonical order. 4. Sort the set of NSEC5 RRs into canonical order.
5. For each NSEC5 RR, set the Next Hashed Owner Name field by using 5. For each NSEC5 RR, set the Next Hashed Owner Name field by using
the owner name of the next NSEC5 RR in the canonical order. If the owner name of the next NSEC5 RR in the canonical order. If
the updated NSEC5 is the last NSEC5 RR in the chain, the owner the updated NSEC5 is the last NSEC5 RR in the chain, the owner
name of the first NSEC5 RR in the chain is used instead. name of the first NSEC5 RR in the chain is used instead.
The NSEC5KEY and NSEC5 RRs MUST have the same class as the zone SOA The NSEC5KEY and NSEC5 RRs MUST have the same class as the zone SOA
skipping to change at page 16, line 17 skipping to change at page 17, line 17
the TTL value of the old NSEC5KEY RRset. the TTL value of the old NSEC5KEY RRset.
The minimal delay between the steps 2. and 3. MUST be the time it The minimal delay between the steps 2. and 3. MUST be the time it
takes for the data to propagate to the authoritative servers, plus takes for the data to propagate to the authoritative servers, plus
the maximum zone TTL value of any of the data in the previous version the maximum zone TTL value of any of the data in the previous version
of the zone. of the zone.
9.4. Secondary Servers 9.4. Secondary Servers
This document does not define mechanism to distribute NSEC5 private This document does not define mechanism to distribute NSEC5 private
keys. keys. See Section 14.3 for discussion on the security requirements
for NSEC5 private keys.
9.5. Zones Using Unknown Hash Algorithms 9.5. Zones Using Unknown Hash Algorithms
Zones that are signed with unknown NSEC5 algorithm or by an Zones that are signed with unknown NSEC5 algorithm or by an
unavailable NSEC5 private key cannot be effectively served. Such unavailable NSEC5 private key cannot be effectively served. Such
zones SHOULD be rejected when loading and servers SHOULD respond with zones SHOULD be rejected when loading and servers SHOULD respond with
RCODE=2 (Server failure) when handling queries that would fall under RCODE=2 (Server failure) when handling queries that would fall under
such zones. such zones.
9.6. Dynamic Updates 9.6. Dynamic Updates
skipping to change at page 19, line 8 skipping to change at page 20, line 15
12.3. Domain Name Length Restrictions 12.3. Domain Name Length Restrictions
The NSEC5 creates additional restrictions on domain name lengths. In The NSEC5 creates additional restrictions on domain name lengths. In
particular, zones with names that, when converted into hashed owner particular, zones with names that, when converted into hashed owner
names exceed the 255 octet length limit imposed by [RFC1035], cannot names exceed the 255 octet length limit imposed by [RFC1035], cannot
use this specification. use this specification.
The actual maximum length of a domain name depends on the length of The actual maximum length of a domain name depends on the length of
the zone name and used NSEC5 algorithm. the zone name and used NSEC5 algorithm.
With FDH-SHA256-SHA256 defined in this document, the SHA-256 hash All NSEC5 algorithms defined in this document use 256-bit NSEC5 hash
function is used to construct NSEC5 hash values. SHA-256 produces a values. Such a value can be encoded in 52 characters in Base32hex
hash of 256 bits, which can be encoded in 52 characters in Base32hex without padding. When constructing the NSEC5 RR owner name, the
without padding. The encoded string is prepended to the name of the encoded hash is prepended to the name of the zone as a single label
zone as a single label, which includes the length field of a single which includes the length field of a single octet. The maximal
octet. The maximal length of the zone name is therefore 202 octets length of the zone name in wire format is therefore 202 octets (255 -
(255 - 53). 53).
13. Performance Considerations 13. Performance Considerations
This section compares NSEC, NSEC3, and NSEC5 with regards to the size This section compares NSEC, NSEC3, and NSEC5 with regards to the size
of denial-of-existence responses and performance impact on the DNS of denial-of-existence responses and performance impact on the DNS
components. components.
13.1. Performance of Cryptographic Operations 13.1. Performance of Cryptographic Operations
Additional performance costs depend on the costs of cryptographic Additional performance costs depend on the costs of cryptographic
operations to a great extent. The following results were retrieved operations to a great extent. The following results were retrieved
with OpenSSL 1.0.1k, running an ordinary laptop on a single-core of a with OpenSSL 1.0.2g, running an ordinary laptop on a single-core of a
CPU manufactured in 2011. The parameters of cryptographic operations CPU manufactured in 2016. The parameters of cryptographic operations
were chosen to reflect the parameters used in the real-world were chosen to reflect the parameters used in the real-world
application of DNSSEC. application of DNSSEC.
Comparison of NSEC3 and NSEC5 hashing performance: 13.1.1. NSEC3 Hashing Performance
o NSEC3 uses multiple iterations of the SHA-1 function with an NSEC3 uses multiple iterations of the SHA-1 function with an
arbitrary salt. The input of the first iteration is the domain arbitrary salt. The input of the first iteration is the domain name
name in wire format together with binary salt; the input of the in wire format together with binary salt; the input of the subsequent
subsequent iterations is the binary digest and the salt. We can iterations is the binary digest and the salt. We can assume that the
assume that the input size will be smaller than 32 octets for most input size will be smaller than 32 octets for most executions.
executions.
The measured implementation gives a stable performance for small The measured implementation gives a stable performance for small
input blocks up to 32 octets. About 3e6 hashes per second can be input blocks up to 32 octets. About 4e6 hashes per second can be
computed given these parameters. computed given these parameters.
The number of additional iterations in NSEC3 parameters will The number of additional iterations in NSEC3 parameters will probably
probably vary between 0 and 20 in reality. Therefore we can vary between 0 and 20 in reality. Therefore we can expect the NSEC3
expect the NSEC3 hash computation performance to be between 2e5 hash computation performance to be between 2e5 and 4e6 hashes per
and 3e6 hashes per second. second.
o The NSEC5 hash is computed in two steps: NSEC5 proof computation 13.1.2. NSEC5 Hashing Performance
followed by hashing of the result. The NSEC5 proof is basically
an RSA signature and the performance will therefore vary for
signing and verification and also for different key sizes. We can
expect that the final hashing will have insignificant impact on
the overall hashing performance.
The measurement of NSEC5 proof computation and verification The NSEC5 hash is computed in two steps: NSEC5 proof computation
resulted into the following numbers: 3e3 sign/s and 4e4 verify/s followed by hashing of the result. As the proof computation involves
for 1024-bit key; 4e2 sign/s and 1e4 verify/s for 2048-bit key; relatively expensive RSA/EC cryptographic operations, the final
and 5e1 sign/s and 3e3 verify/s for 4096-bit key. hashing will have insignificant impact on the overall performance.
We can also expect difference between NSEC5 hashing (signing) and
verification time.
The final SHA-256 hashing is about two orders of magnitude faster The measurement results for various NSEC5 algorithms and key sizes
given the input block size matching the NSEC5 proof result size. are summarized in the following table:
Picking a moderate key size of 2048-bits, the NSEC5 hash +----------------------+--------+-----------+----------+------------+
computation performance will be in the order of 10^2 issued hashes | NSEC5 algorithm | Key | Proof | Perf. | Perf. |
per second and 10^4 validated hashes per second. | | size | size | (hash/s) | (verify/s) |
| | (bits) | (octets) | | |
+----------------------+--------+-----------+----------+------------+
| RSAFDH-SHA256-SHA256 | 1024 | 128 | 9500 | 120000 |
| RSAFDH-SHA256-SHA256 | 2048 | 256 | 1500 | 46000 |
| RSAFDH-SHA256-SHA256 | 4096 | 512 | 200 | 14000 |
| EC-P256-SHA256 | 256 | 81 | 4700 | 4000 |
+----------------------+--------+-----------+----------+------------+
According to the results, the NSEC5 hashing is about three orders of Picking a moderate key size of 2048-bits for RSAFDH-SHA256-SHA256,
magnitude slower than NSEC3 hashing and the NSEC5 hash verification the NSEC5 hash computation performance will be in the order of 10^3
is about one order of magnitude slower than NSEC3 hash verification. issued hashes per second and 10^4 validated hashes per second.
Comparison of signing and verification performance of different EC-P256-SHA256 trades off verification performance for shorter proof
DNSSEC signing algorithms: size and faster query processing at the nameserver. In that case,
both hash computation and verification performance will be in the
order of 10^3 hashes per second.
+-----------------+---------+-----------+-------------+-------------+ 13.1.3. DNSSEC Signing Performance
| Algorithm | Key | Signature | Performance | Performance |
| | size | size | (sign/s) | (verify/s) | For completeness, the following table sumarrizes the signing and
| | (bits) | (octets) | | | verification performance for different DNSSEC signing algorithms:
+-----------------+---------+-----------+-------------+-------------+
| RSASHA256 | 1024 | 128 | 2000 | 40000 | +------------------+--------+-----------+-------------+-------------+
| RSASHA256 | 2048 | 256 | 400 | 10000 | | Algorithm | Key | Signature | Performance | Performance |
| RSASHA256 | 4096 | 512 | 50 | 3000 | | | size | size | (sign/s) | (verify/s) |
| ECDSAP256SHA256 | 256 | 64 | 5000 | 1000 | | | (bits) | (octets) | | |
| ECDSAP384SHA384 | 384 | 96 | 3000 | 600 | +------------------+--------+-----------+-------------+-------------+
+-----------------+---------+-----------+-------------+-------------+ | RSASHA256 | 1024 | 128 | 9000 | 140000 |
| RSASHA256 | 2048 | 256 | 1500 | 47000 |
| RSASHA256 | 4096 | 512 | 200 | 14000 |
| ECDSAP256SHA256 | 256 | 64 | 7400 | 4000 |
| ECDSAP384SHA384 | 384 | 96 | 5000 | 1000 |
| ECDSAP256SHA256* | 256 | 64 | 24000 | 11000 |
+------------------+--------+-----------+-------------+-------------+
* highly optimized implementation
The retrieved values are important primarily for the purpose of The retrieved values are important primarily for the purpose of
evaluating performance of response validation. The signing evaluating performance of response validation. The signing
performance is not that important because the zone is usually signed performance is usually not that important because the zone is signed
offline. offline. However, when online signing is used, signing performace is
also important.
13.2. Authoritative Server Startup 13.2. Authoritative Server Startup
This section compares additional server startup cost based on the This section compares additional server startup cost based on the
used authenticated denial mechanism. used authenticated denial mechanism.
NSEC There are no special requirements on processing of a NSEC- NSEC There are no special requirements on processing of a NSEC-
signed zone during an authoritative server startup. The server signed zone during an authoritative server startup. The server
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.
skipping to change at page 21, line 45 skipping to change at page 23, line 23
In the worst case, the following additional records authenticating In the worst case, the following additional records authenticating
the denial will be included into the response: the denial will be included into the response:
o Up to two NSEC records and their associated RRSIG records. o Up to two NSEC records and their associated RRSIG records.
o Up to three NSEC3 records and their associated RRSIG records. o Up to three NSEC3 records and their associated RRSIG records.
o Up to two NSEC5 records and their associated NSEC5PROOF and RRSIG o Up to two NSEC5 records and their associated NSEC5PROOF and RRSIG
records. records.
The following table compares the size of NSEC, NSEC3, and NSEC5
records. We assume the SHA-1 hash algorithm for NSEC3 and the FDH-
SHA256-SHA256 algorithm for NSEC5.
+-------+------------+---------------+-----------------------+
| | Fixed part | Common part | RR type-specific part |
+-------+------------+---------------+-----------------------+
| NSEC | 10 octets | Type Bit Maps | Owner Name, Next Name |
| NSEC3 | 64 octets | Type Bit Maps | Salt |
| NSEC5 | 101 octets | Type Bit Maps | - |
+-------+------------+---------------+-----------------------+
The size covers complete RR representation in wire format:
o The Fixed part includes length of all fixed-size fields in the RR;
and also a size of generally variable-sized fields whose length
can determined from the used parameters (e.g., the NSEC3 owner
name consists from one label encoding the hash and a compression
pointer to zone apex).
o The Common part includes the only field shared among the RR types.
o The RR type-specific part contains unique fields present in the RR
types whose length will vary. Note that the Owner Name can be
compressed, but Next Name must not. Also note that the Salt in
NSEC3 will have constant size for all NSEC3 records in the chain.
The size of RRSIG RR is a sum of length of possibly compressed RR
owner name, 28 octets for fixed-size fields, the length of
uncompressed signer name, and the length of the signature.
The size of NSEC5PROOF RR is a sum of length of possibly compressed
RR owner name, 2 octets for fixed-size fields, and the length of the
proof.
The following list summarizes the increase of the DNS response size
for authenticated denial worst-case scenario. As a significant part
of the increase is caused by the used DNSSEC signing algorithm, the
summary includes two variants: RSA stands for the RSASHA256 algorithm
with 2048-bit key and ECDSA stands for the ECDSAP256SHA256 algorithm.
For NSEC5, FDH-SHA256-SHA256 with 2048-bit key is used.
o NSEC:
* 4 x compressed domain name
* 4 x uncompressed domain name
* 2 x type bit bitmap
* 588 octets (RSA) or 204 octets (ECDSA)
o NSEC3:
* 3 x compressed domain name
* 3 x uncompressed domain name
* 3 x salt
* 3 x type bit map
* 969 octets (RSA) or 393 octets (ECDSA)
o NSEC5:
* 4 x compressed domain name
* 2 x uncompressed domain name
* 2 x type bit map
* 1286 octets (RSA) or 902 octets (ECDSA)
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:
skipping to change at page 23, line 45 skipping to change at page 23, line 46
* 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
As anticipated, NSEC is the most efficient authenticated denial 13.4. Response Lengths
mechanism as for response size and performance cost. The bottleneck
of NSEC5 is the NSEC5 proof computation. If the proofs are
precomputed for domain names in the zone, the server has to compute
just one NSEC5 proof per answer. But it will still be more expensive
than NSEC3 and the same applies for the response size.
As for the response processing, the validation cost reflects from the [nsec5ecc] precisely measured response lengths for NSEC, NSEC3 and
records present in the response. Again, the NSEC validation seems to NSEC5 using empirical data from a sample second-level domain
be the most inexpensive. However the difference between RSA and containing about 1000 names. The sample zone was signed several
ECDSA verification performance is huge and for some parameters, NSEC3 times with different DNSSEC signing algorithms and different
is faster to validate than NSEC5 and vice versa. authenticated denial of existence mechanisms.
For DNSKEY algorithms, RSASHA256 (2048-bit) and ECDSAPSHA256 were
considered. For authenticated denial, NSEC, NSEC3, NSEC5 with
RSAFDH-SHA256-SHA256 (2048-bit), and NSEC5 with EC-P256-SHA256 were
considered. (Note that NSEC5 with EC-ED25519-SHA256 is identical to
EC-P256-SHA256 as for response size.)
For each instance of the signed zone, Name Error responses were
collected by issuing DNS queries with a random five-character label
prepended to each actual record name from the zone. The average and
standard deviation of the length of these responses are shown below.
+-----------+--------------+------------------+---------------------+
| | DNSKEY | Average length | Standard deviation |
| | algorithm | (octets) | (octets) |
+-----------+--------------+------------------+---------------------+
| NSEC | RSA | 1116 | 48 |
| NSEC | ECDSA | 543 | 24 |
| NSEC3 | RSA | 1440 | 170 |
| NSEC3 | ECDSA | 752 | 84 |
| NSEC5/RSA | RSA | 1767 | 7 |
| NSEC5/EC | ECDSA | 839 | 7 |
+-----------+--------------+------------------+---------------------+
13.5. Summary
As anticipated, NSEC and NSEC3 are the most efficient authenticated
denial mechanisms, in terms of computation for authoritative server
and resolver. NSEC also has the shortest response lengths. However,
these mechanisms do not prevent zone enumeration.
Regarding mechanisms that do prevent zone enumeration, NSEC5 should
be examined in contrast with Minimally Covering NSEC Records or NSEC3
White Lies [RFC7129]. The following table summarizes their
comparison in terms of response size, performance at the
authoritative server, and performance at the resolver. For NSEC3
White Lies, RSASHA256 (2048-bit) and ECDSAPSHA256 were considered,
and for NSEC5, RSAFDH-SHA256-SHA256 (2048-bit) and EC-P256-SHA256
were considered.
+---------------+-----------------+------------------+--------------+
| Algorithm | Response length | Authoritative | Resolver |
| | (octets) | (ops/sec) | (ops/sec) |
+---------------+-----------------+------------------+--------------+
| NSEC3WL/RSA | 1440 | 1500 | 47000 |
| NSEC3WL/ECDSA | 752 | 7400 | 4000 |
| NSEC5/RSA | 1767 | 1500 | 46000 |
| NSEC5/EC | 839 | 4700 | 4000 |
+---------------+-----------------+------------------+--------------+
NSEC5 responses lengths are only slighly longer than NSEC3 response
lengths: NSEC5/RSA has responses that are about 22% longer than
NSEC3/RSA, while NSEC5/EC has responses that are about 13% longer
than NSEC3/ECDSA. For both NSEC3 and NSEC5, it is clear that EC-
based solutions give much shorter responses.
Regarding the computation performance, with RSA the difference is
negligible for both nameserver and resolver, whereas with the EC-
based schemes there is no slowdown for the resolver, and a slowdown
of 1.5x for the server. Importantly, we expect the slowdown to be
smaller in practice because NSEC3 entails three signing/verifying
computations per query in the worst case (closest encloser, next
closer, wildcard at closest encloser) whereas NSEC5 requires only
two. The table above does not capture this issue, it just measures
number of signing/verifying operations per second. Future versions
of this draft will more accurately measure and compare NSEC5
performance.
Note also that while NSEC3 White Lies outperforms NSEC5 for certain
cases, NSEC3 White Lies require authoratitive nameserver to store the
private zone-signing key, making each nameserver a potential point of
compromise.
14. Security Considerations 14. Security Considerations
14.1. Zone Enumeration Attacks 14.1. Zone Enumeration Attacks
NSEC5 is robust to zone enumeration via offline dictionary attacks by NSEC5 is robust to zone enumeration via offline dictionary attacks by
any attacker that does not know the NSEC5 private key. Without the any attacker that does not know the NSEC5 private key. Without the
private NSEC5 key, that attacker cannot compute the NSEC5 proof that private NSEC5 key, that attacker cannot compute the NSEC5 proof that
corresponds to a given name; the only way it can learn the NSEC5 corresponds to a given name; the only way it can learn the NSEC5
proof value for a given name is by sending a queries for that name to proof value for a given name is by sending a queries for that name to
skipping to change at page 24, line 42 skipping to change at page 26, line 11
highly unlikely (on the order of 1 in 2^128). Note that DNSSEC highly unlikely (on the order of 1 in 2^128). Note that DNSSEC
already relies on the presumption that a cryptographic hash function already relies on the presumption that a cryptographic hash function
is collision resistant, since these hash functions are used for is collision resistant, since these hash functions are used for
generating and validating signatures and DS RRs. See also the generating and validating signatures and DS RRs. See also the
discussion on key lengths in [nsec5]. discussion on key lengths in [nsec5].
14.3. Compromise of the Private NSEC5 Key 14.3. Compromise of the Private NSEC5 Key
NSEC5 requires authoritative servers to hold the private NSEC5 key, NSEC5 requires authoritative servers to hold the private NSEC5 key,
but not the private zone-signing keys or the private key-signing keys but not the private zone-signing keys or the private key-signing keys
for the zone. The private NSEC5 key needs only be as secure as the for the zone.
DNSSEC records whose the privacy (against zone-enumeration attacks)
that NSEC5 is protecting. This is because even an adversary that The private NSEC5 key needs only be as secure as the DNSSEC records
knows the private NSEC5 key cannot modify the contents of the zone; whose the privacy (against zone-enumeration attacks) that NSEC5 is
this is because the zone contents are signed using the private zone- protecting. This is because even an adversary that knows the private
signing key, while the private NSEC5 key is only used to compute NSEC5 key cannot modify the contents of the zone; this is because the
NSEC5 proof values. Thus, a compromise of the private NSEC5 keys zone contents are signed using the private zone-signing key, while
does not lead to a compromise of the integrity of the DNSSEC record the private NSEC5 key is only used to compute NSEC5 proof values.
in the zone; instead, all that is lost is privacy against zone Thus, a compromise of the private NSEC5 keys does not lead to a
enumeration, if the attacker that knows the private NSEC5 key can compromise of the integrity of the DNSSEC record in the zone;
compute NSEC5 hashes offline, and thus launch offline dictionary instead, all that is lost is privacy against zone enumeration, if the
attacks. Thus, a compromise of the private NSEC5 key effectively attacker that knows the private NSEC5 key can compute NSEC5 hashes
downgrades the security of NSEC5 to that of NSEC3. A formal offline, and thus launch offline dictionary attacks. Thus, a
cryptographic proof of this property is in [nsec5]. compromise of the private NSEC5 key effectively downgrades the
security of NSEC5 to that of NSEC3. A formal cryptographic proof of
this property is in [nsec5].
If a zone owner wants to preserve this property of NSEC5, the zone
owner SHOULD choose the NSEC5 private key to be different from the
private zone-signing keys or key-signing keys for the zone.
14.4. Key Length Considerations 14.4. Key Length Considerations
The NSEC5 key must be long enough to withstand attacks for as long as The NSEC5 key must be long enough to withstand attacks for as long as
the privacy of the zone is important. Even if the NSEC5 key is the privacy of the zone is important. Even if the NSEC5 key is
rolled frequently, its length cannot be too short, because zone rolled frequently, its length cannot be too short, because zone
privacy may be important for a period of time longer than the privacy may be important for a period of time longer than the
lifetime of the key. (For example, an attacker might collect the lifetime of the key. (For example, an attacker might collect the
entire chain of NSEC5 RR for the zone over one short period, and entire chain of NSEC5 RR for the zone over one short period, and
then, later (even after the NSEC5 key expires) perform an offline then, later (even after the NSEC5 key expires) perform an offline
skipping to change at page 26, line 5 skipping to change at page 27, line 28
NSEC5 value XXX. NSEC5 value XXX.
NSEC5PROOF value XXX. NSEC5PROOF value XXX.
This document creates a new IANA registry for NSEC5 algorithms. This This document creates a new IANA registry for NSEC5 algorithms. This
registry is named "DNSSEC NSEC5 Algorithms". The initial content of registry is named "DNSSEC NSEC5 Algorithms". The initial content of
the registry is: the registry is:
0 is Reserved. 0 is Reserved.
1 is FDH-SHA256-SHA256. 1 is RSAFDH-SHA256-SHA256.
2-255 is Available for assignment. 2 is EC-P256-SHA256.
3 is EC-ED25519-SHA256.
4-255 is Available for assignment.
This document updates the IANA registry "DNS Security Algorithm This document updates the IANA registry "DNS Security Algorithm
Numbers" by defining following aliases: Numbers" by defining following aliases:
XXX is NSEC5-RSASHA256, alias for RSASHA256 (8). XXX is NSEC5-RSASHA256, alias for RSASHA256 (8).
XXX is NSEC5-RSASHA512, alias for RSASHA512 (10). XXX is NSEC5-RSASHA512, alias for RSASHA512 (10).
XXX is NSEC5-ECDSAP256SHA256 alias for ECDSAP256SHA256 (13). XXX is NSEC5-ECDSAP256SHA256 alias for ECDSAP256SHA256 (13).
XXX is NSEC5-ECDSAP384SHA384 alias for ECDSAP384SHA384 (14). XXX is NSEC5-ECDSAP384SHA384 alias for ECDSAP384SHA384 (14).
16. Contributors 16. Contributors
This document would not be possible without help of Moni Naor This document would not be possible without help of Moni Naor
(Weizmann Institute), Dimitrios Papadopoulos (Boston University), (Weizmann Institute), Sachin Vasant (Cisco Systems), Leonid Reyzin
Sachin Vasant (Cisco Systems), Leonid Reyzin (Boston University), and (Boston University), and Asaf Ziv (Weizmann Institute) who
Asaf Ziv (Weizmann Institute) who contributed to the design of NSEC5, contributed to the design of NSEC5, and Ondrej Sury (CZ.NIC Labs) who
and Ondrej Sury (CZ.NIC Labs) who provided advice on its provided advice on its implementation.
implementation.
17. References 17. References
17.1. Normative References 17.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997. RFC 2136, DOI 10.17487/RFC2136, April 1997,
<http://www.rfc-editor.org/info/rfc2136>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997. Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<http://www.rfc-editor.org/info/rfc2181>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998. NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<http://www.rfc-editor.org/info/rfc2308>.
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
Name System (DNS)", RFC 3110, May 2001. Domain Name System (DNS)", RFC 3110, DOI 10.17487/RFC3110,
May 2001, <http://www.rfc-editor.org/info/rfc3110>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003. Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC Rose, "DNS Security Introduction and Requirements",
4033, March 2005. RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, DOI 10.17487/RFC4034, March 2005,
<http://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<http://www.rfc-editor.org/info/rfc4035>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman
Groups for Use with IETF Standards", RFC 5114,
DOI 10.17487/RFC5114, January 2008,
<http://www.rfc-editor.org/info/rfc5114>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008. Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<http://www.rfc-editor.org/info/rfc5155>.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<http://www.rfc-editor.org/info/rfc6234>.
[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital
Signature Algorithm (DSA) for DNSSEC", RFC 6605,
DOI 10.17487/RFC6605, April 2012,
<http://www.rfc-editor.org/info/rfc6605>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <http://www.rfc-editor.org/info/rfc7748>.
[I-D.ietf-curdle-dnskey-ed25519]
Sury, O. and R. Edmonds, "Ed25519 for DNSSEC", draft-ietf-
curdle-dnskey-ed25519-01 (work in progress), February
2016.
[FIPS-186-3]
National Institute for Standards and Technology, "Digital
Signature Standard (DSS)", FIPS PUB 186-3, June 2009.
[SECG1] Standards for Efficient Cryptography Group (SECG), "SEC 1:
Elliptic Curve Cryptography", Version 2.0, May 2009,
<http://www.secg.org/sec1-v2.pdf>.
17.2. Informative References 17.2. Informative References
[nsec5] Goldberg, S., Naor, M., Papadopoulos, D., Reyzin, L., [nsec5] Goldberg, S., Naor, M., Papadopoulos, D., Reyzin, L.,
Vasant, S., and A. Ziv, "NSEC5: Provably Preventing DNSSEC Vasant, S., and A. Ziv, "NSEC5: Provably Preventing DNSSEC
Zone Enumeration", July 2014. Zone Enumeration", in NDSS'15, July 2014.
[nsec5ecc]
Goldberg, S., Naor, M., Papadopoulos, D., and L. Reyzin,
"NSEC5 from Elliptic Curves", in ePrint Cryptology Archive
2016/083, January 2016.
[nsec3gpu] [nsec3gpu]
Wander, M., Schwittmann, L., Boelmann, C., and T. Weis, Wander, M., Schwittmann, L., Boelmann, C., and T. Weis,
"GPU-Based NSEC3 Hash Breaking", in IEEE Symp. Network "GPU-Based NSEC3 Hash Breaking", in IEEE Symp. Network
Computing and Applications (NCA), 2014. Computing and Applications (NCA), 2014.
[nsec3walker] [nsec3walker]
Bernstein, D., "Nsec3 walker", 2011, Bernstein, D., "Nsec3 walker", 2011,
<http://dnscurve.org/nsec3walker.html>. <http://dnscurve.org/nsec3walker.html>.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781, December Operational Practices, Version 2", RFC 6781,
2012. DOI 10.17487/RFC6781, December 2012,
<http://www.rfc-editor.org/info/rfc6781>.
[RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of
Existence in the DNS", RFC 7129, February 2014. Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,
February 2014, <http://www.rfc-editor.org/info/rfc7129>.
Appendix A. Full Domain Hash Algorithm Appendix A. RSA Full Domain Hash Algorithm
The Full Domain Hash (FDH) is a RSA-based scheme that allows The Full Domain Hash (FDH) is a RSA-based scheme that allows
authentication of hashes using public-key cryptography. authentication of hashes using public-key cryptography.
In this document, the notation from [RFC3447] is used. In this document, the notation from [RFC3447] is used.
Used parameters: Used parameters:
(n, e) - RSA public key (n, e) - RSA public key
skipping to change at page 29, line 50 skipping to change at page 32, line 48
2. m = RSAVP1((n, e), s) 2. m = RSAVP1((n, e), s)
3. EM = I2OSP(m, k - 1) 3. EM = I2OSP(m, k - 1)
4. EM' = MGF1(M, k - 1) 4. EM' = MGF1(M, k - 1)
5. If EM and EM' are the same, output "valid signature"; else output 5. If EM and EM' are the same, output "valid signature"; else output
"invalid signature". "invalid signature".
Appendix B. Change Log Appendix B. Elliptic Curve VRF
The Elliptic Curve Verifiable Random Function (VRF) is a EC-based
scheme that allows authentication of hashes using public-key
cryptography.
Fixed options:
G - EC group
Used parameters:
g^x - EC public key
x - EC private key
q - primer order of group G
g - generator of group G
Used primitives:
"" - empty octet string
|| - octet string concatenation
p^k - EC point multiplication
p1*p2 - EC point addition
SHA256 - hash function SHA-256 as specified in [RFC6234]
ECP2OS - EC point to octet string conversion with point
compression as specified in Section 2.3.3 of [SECG1]
OS2ECP - octet string to EC point conversion with point
compression as specified in Section 2.3.4 of [SECG1]
B.1. ECVRF Hash To Curve
ECVRF_hash_to_curve(m)
Input:
m - value to be hashed, an octet string
Output:
h - hashed value, EC point
Steps:
1. c = 0
2. C = I2OSP(c, 4)
3. xc = SHA256(m || C)
4. p = 0x02 || xc
5. If p is not a valid octet string representing encoded compressed
point in G:
A. c = c + 1
B. Go to step 2.
6. h = OS2ECP(p)
7. Output h
B.2. ECVRF Auxiliary Functions
B.2.1. ECVRF Hash Points
ECVRF_hash_points(p_1, p_2, ..., p_n)
Input:
p_x - EC point in G
Output:
h - hash value, integer between 0 and 2^128-1
Steps:
1. P = ""
2. for p in [p_1, p_2, ... p_n]:
P = P || ECP2OS(p)
3. h' = SHA256(P)
4. h = OS2IP(first 16 octets of h')
5. Output h
B.2.2. ECVRF Proof To Hash
ECVRF_proof_to_hash(gamma)
Input:
gamma - VRF proof, EC point in G with coordinates (x, y)
Output:
beta - VRF hash, octet string (32 octets)
Steps:
1. beta = I2OSP(x, 32)
2. Output beta
Note: Because of the format of compressed form of an elliptic curve,
the hash can be retrieved from an encoded gamma simply by omitting
the first octet of the gamma.
B.2.3. ECVRF Decode Proof
ECVRF_decode_proof(pi)
Input:
pi - VRF proof, octet string (81 octets)
Output:
gamma - EC point
c - integer between 0 and 2^128-1
s - integer between 0 and 2^256-1
Steps:
1. let gamma', c', s' be pi split after 33-rd and 49-th octet
2. gamma = OS2ECP(gamma')
3. c = OS2IP(c')
4. s = OS2IP(s')
5. Output gamma, c, and s
B.3. ECVRF Signing
ECVRF_sign(g^x, x, alpha)
Input:
g^x - EC public key
x - EC private key
alpha - message to be signed, octet string
Output:
pi - VRF proof, octet string (81 octets)
beta - VRF hash, octet string (32 octets)
Steps:
1. h = ECVRF_hash_to_curve(alpha)
2. gamma = h^x
3. choose a nonce k from [0, q-1]
4. c = ECVRF_hash_points(g, h, g^x, h^x, g^k, h^k)
5. s = k - c*q mod q
6. pi = ECP2OS(gamma) || I2OSP(c, 16) || I2OSP(s, 32)
7. beta = h2(gamma)
8. Output pi and beta
B.4. ECVRF Verification
ECVRF_VERIFY(g^x, pi, alpha)
Input:
g^x - EC public key
pi - VRF proof, octet string
alpha - message to verify, octet string
Output:
"valid signature" or "invalid signature"
beta - VRF hash, octet string (32 octets)
Steps:
1. gamma, c, s = ECVRF_decode_proof(pi)
2. u = (g^x)^c * g^s
3. h = ECVRF_hash_to_curve(alpha)
4. v = gamma^c * h^s
5. c' = ECVRF_hash_points(g, h, g^x, gamma, u, v)
6. beta = ECVRF_proof_to_hash(gamma)
7. If c and c' are the same, output "valid signature"; else output
"invalid signature". Output beta.
[[CREF1: TODO: check validity of gamma before hashing --Jan]]
Appendix C. Change Log
Note to RFC Editor: if this document does not obsolete an existing Note to RFC Editor: if this document does not obsolete an existing
RFC, please remove this appendix before publication as an RFC. RFC, please remove this appendix before publication as an RFC.
pre 00 - initial version of the document submitted to mailing list pre 00 - initial version of the document submitted to mailing list
only only
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
Appendix C. Open Issues 02 - Elliptic Curve based VRF for NSEC5 proofs; response sizes
based on empirical data
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].
skipping to change at page 31, line 4 skipping to change at page 38, line 37
Authors' Addresses Authors' Addresses
Jan Vcelak Jan Vcelak
CZ.NIC CZ.NIC
Milesovska 1136/5 Milesovska 1136/5
Praha 130 00 Praha 130 00
CZ CZ
EMail: jan.vcelak@nic.cz EMail: jan.vcelak@nic.cz
Sharon Goldberg Sharon Goldberg
Boston University Boston University
111 Cummington St, MCS135 111 Cummington St, MCS135
Boston, MA 02215 Boston, MA 02215
USA USA
EMail: goldbe@cs.bu.edu EMail: goldbe@cs.bu.edu
Dimitrios Papadopoulos
Boston University
111 Cummington St, MCS135
Boston, MA 02215
USA
EMail: dipapado@bu.edu
 End of changes. 74 change blocks. 
312 lines changed or deleted 655 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/