draft-ietf-dnsext-dnssec-algo-signal-02.txt | draft-ietf-dnsext-dnssec-algo-signal-03.txt | |||
---|---|---|---|---|
DNS Extensions Working Group S. Crocker | DNS Extensions Working Group S. Crocker | |||
Internet-Draft Shinkuro Inc. | Internet-Draft Shinkuro Inc. | |||
Intended status: Standards Track S. Rose | Intended status: Standards Track S. Rose | |||
Expires: January 7, 2012 NIST | Expires: July 6, 2012 NIST | |||
July 6, 2011 | January 3, 2012 | |||
Signaling Cryptographic Algorithm Understanding in DNSSEC | Signaling Cryptographic Algorithm Understanding in DNSSEC | |||
draft-ietf-dnsext-dnssec-algo-signal-02 | draft-ietf-dnsext-dnssec-algo-signal-03 | |||
Abstract | Abstract | |||
The DNS Security Extensions (DNSSEC) were developed to provide origin | The DNS Security Extensions (DNSSEC) were developed to provide origin | |||
authentication and integrity protection for DNS data by using digital | authentication and integrity protection for DNS data by using digital | |||
signatures. These digital signatures can be generated using | signatures. These digital signatures can be generated using | |||
different algorithms. This draft sets out to specify a way for | different algorithms. This draft sets out to specify a way for | |||
validating end-system resolvers to signal to a server which | validating end-system resolvers to signal to a server which | |||
cryptographic algorithms they support. | cryptographic algorithms they support. | |||
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 January 7, 2012. | This Internet-Draft will expire on July 6, 2012. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2012 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 | |||
2. Signaling DNSSEC Algorithm Understood (DAU) Using EDNS . . . . 3 | 2. Signaling DNSSEC Algorithm Understood (DAU) Using EDNS . . . . 3 | |||
3. Client Considerations . . . . . . . . . . . . . . . . . . . . . 4 | 3. Client Considerations . . . . . . . . . . . . . . . . . . . . . 4 | |||
3.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . . 5 | 3.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3.2. Validating Stub Resolvers . . . . . . . . . . . . . . . . . 5 | 3.2. Validating Stub Resolvers . . . . . . . . . . . . . . . . . 5 | |||
3.3. Non-Validating Stub Resolvers . . . . . . . . . . . . . . . 5 | 3.3. Non-Validating Stub Resolvers . . . . . . . . . . . . . . . 5 | |||
3.4. Recursive Resolvers . . . . . . . . . . . . . . . . . . . . 5 | 3.4. Recursive Resolvers . . . . . . . . . . . . . . . . . . . . 5 | |||
3.4.1. Validating Recursive Resolvers . . . . . . . . . . . . 5 | 3.4.1. Validating Recursive Resolvers . . . . . . . . . . . . 5 | |||
3.4.2. Non-validating Recursive Resolvers . . . . . . . . . . 6 | 3.4.2. Non-validating Recursive Resolvers . . . . . . . . . . 5 | |||
4. Intermediate System Considerations . . . . . . . . . . . . . . 6 | 4. Intermediate System Considerations . . . . . . . . . . . . . . 6 | |||
5. Server Considerations . . . . . . . . . . . . . . . . . . . . . 6 | 5. Server Considerations . . . . . . . . . . . . . . . . . . . . . 6 | |||
6. Traffic Analysis Considerations . . . . . . . . . . . . . . . . 6 | 6. Traffic Analysis Considerations . . . . . . . . . . . . . . . . 6 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 | |||
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 | 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 | |||
1. Introduction | 1. Introduction | |||
The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034] and | The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034] and | |||
[RFC4035] were developed to provide origin authentication and | [RFC4035] were developed to provide origin authentication and | |||
integrity protection for DNS data by using digital signatures. Each | integrity protection for DNS data by using digital signatures. Each | |||
digital signature RR (RRSIG) contains an algorithm code number. | digital signature RR (RRSIG) contains an algorithm code number. | |||
These algorithm codes tells validators which cryptographic algorithm | These algorithm codes tells validators which cryptographic algorithm | |||
was used to generate the digital signature. Authentication across | was used to generate the digital signature. | |||
delegation boundaries is maintained by storing a hash of a subzone's | ||||
key in the parent zone stored in a Delegation Signer (DS) RR. These | ||||
DS RR's contain a second code number to identify the hash algorithm | ||||
used to construct the DS RR. | ||||
This draft sets out to specify a way for validating end-system | This draft sets out to specify a way for validating end-system | |||
resolvers to tell a server which cryptographic and/or hash algorithms | resolvers to tell a server which cryptographic algorithms they | |||
they support in a DNS query. This is done using the EDNS attribute | support in a DNS query. This is done using the EDNS attribute values | |||
values in the OPT meta-RR [RFC2671]. | in the OPT meta-RR [RFC2671]. | |||
This proposed EDNS option serves to measure the acceptance and use of | This proposed EDNS option serves to measure the acceptance and use of | |||
new digital signing and hash algorithms. This algorithm signaling | new digital signing algorithms. This algorithm signaling option can | |||
option can be used by zone administrators as a gauge to measure the | be used by zone administrators as a gauge to measure the successful | |||
successful deployment of code that implements a newly deployed | deployment of code that implements a newly deployed digital signature | |||
digital signature or hash algorithm used with DNSSEC. A zone | algorithm used with DNSSEC. A zone administrator may be able to | |||
administrator may be able to determine when to stop serving the old | determine when to stop serving the old algorithm when the server sees | |||
algorithm when the server sees that a significant number of its | that a significant number of its clients signal that they are able to | |||
clients signal that they are able to accept the new algorithm. Note | accept the new algorithm. Note that this survey may be conducted | |||
that this survey may be conducted over the period of years before a | over the period of years before a tipping point is seen. | |||
tipping point is seen. | ||||
This draft does not seek to include another process for including new | This draft does not seek to include another process for including new | |||
algorithms for use with DNSSEC (see . It also does not address the | algorithms for use with DNSSEC (see . It also does not address the | |||
question of which algorithms are to be included in any official list | question of which algorithms are to be included in any official list | |||
of mandatory or recommended cryptographic algorithms for use with | of mandatory or recommended cryptographic algorithms for use with | |||
DNSSEC. Rather, this document specifies a means by which a client | DNSSEC. Rather, this document specifies a means by which a client | |||
query can signal a set of algorithms it implements. | query can signal a set of algorithms it implements. | |||
2. Signaling DNSSEC Algorithm Understood (DAU) Using EDNS | 2. Signaling DNSSEC Algorithm Understood (DAU) Using EDNS | |||
The ENDS0 specification outlined in [RFC2671] defines a way to | The ENDS0 specification outlined in [RFC2671] defines a way to | |||
include new options using a standardized mechanism. These options | include new options using a standardized mechanism. These options | |||
are contained in the RDATA of the OPT meta-RR. This document defines | are contained in the RDATA of the OPT meta-RR. This document defines | |||
a new EDNS0 option for a client to signal which algorithms the client | a new EDNS0 option for a client to signal which algorithms the client | |||
supports. | supports. | |||
The figure below shows how the signaling attribute is defined in the | The figure below shows how the digital signature signaling attribute | |||
RDATA of the OPT RR specified in [RFC2671]: | is defined in the RDATA of the OPT RR specified in [RFC2671]: | |||
0 8 16 | 0 8 16 | |||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |||
| OPTION-CODE (TBD) | | | OPTION-CODE (TBD) | | |||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |||
| DIGITAL-SIG-LIST-LENGTH | | | DIGITAL-SIG-LIST-LENGTH | | |||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |||
| ALG-CODE | ... \ | | ALG-CODE | ... \ | |||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |||
| DS-HASH-LIST-LENGTH | | ||||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| HASH-CODE | ... \ | ||||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
OPTION-CODE is the code for the DNSSEC Algorithm Understood (DAU) | OPTION-CODE is the code for the DNSSEC Algorithm Understood (DAU) | |||
option. Its value is fixed at TBD. | option. Its value is fixed at TBD. | |||
DIGITAL-SIG-LIST-LENGTH is the length of the list of digital | DIGITAL-SIG-LIST-LENGTH is the length of the list of digital | |||
signature algorithms in octets. DNSSEC algorithm codes are 1 octet | signature algorithms in octets. DNSSEC algorithm codes are 1 octet | |||
long so this value is the number of octets. | long so this value is the number of octets. | |||
ALG-CODE is the list of assigned values of DNSSEC zone signing | ALG-CODE is the list of assigned values of DNSSEC zone signing | |||
algorithms that the client indicates as understood. The values | algorithms that the client indicates as understood. The values | |||
SHOULD be in descending order of preference, with the most preferred | SHOULD be in descending order of preference, with the most preferred | |||
algorithm first. For example, if a validating client implements RSA/ | algorithm first. For example, if a validating client implements RSA/ | |||
SHA-1, RSA/SHA-256 and prefers the latter, the value of ALG-CODE | SHA-1, RSA/SHA-256 and prefers the latter, the value of ALG-CODE | |||
would be: 8 (RSA/SHA-256), 5 (RSA/SHA-1). | would be: 8 (RSA/SHA-256), 5 (RSA/SHA-1). | |||
DS-HASH-LIST-LENGTH is the length of the list of hash algorithms in | ||||
octets. DNSSEC DS hash codes are 1 octet long so this value is the | ||||
number of octets. | ||||
HASH-CODE is the list of assigned values of DNSSEC DS hash algorithms | ||||
that the client indicates as understood. Like the ALG-CODE above, | ||||
the values SHOULD be in descending order of preference, with the most | ||||
preferred algorithm first. | ||||
3. Client Considerations | 3. Client Considerations | |||
A validating end-system resolver sets the DAU option in the OPT | A validating end-system resolver sets the DAU option in the OPT | |||
meta-RR when sending a query. The validating end-system resolver | meta-RR when sending a query. The validating end-system resolver | |||
sets the value(s) in the order of preference, with the most preferred | sets the value(s) in the order of preference, with the most preferred | |||
algorithm(s) first as described in section 2. The end-system | algorithm(s) first as described in section 2. The end-system | |||
resolver SHOULD also set the DNSSEC-OK bit [RFC4035] to indicate that | resolver SHOULD also set the DNSSEC-OK bit [RFC4035] to indicate that | |||
it wishes to receive DNSSEC RRs in the response. | it wishes to receive DNSSEC RRs in the response. | |||
Note that the PRIVATEDNS (253) and/or the PRIVATEOID (254) codes | Note that the PRIVATEDNS (253) and/or the PRIVATEOID (254) codes | |||
End of changes. 13 change blocks. | ||||
40 lines changed or deleted | 22 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |