draft-ietf-dnsext-dnssec-algo-signal-05.txt | draft-ietf-dnsext-dnssec-algo-signal-06.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: September 27, 2012 NIST | Expires: November 2, 2012 NIST | |||
March 26, 2012 | May 1, 2012 | |||
Signaling Cryptographic Algorithm Understanding in DNSSEC | Signaling Cryptographic Algorithm Understanding in DNSSEC | |||
draft-ietf-dnsext-dnssec-algo-signal-05 | draft-ietf-dnsext-dnssec-algo-signal-06 | |||
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 and hash algorithms they support. | cryptographic algorithms and hash 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 September 27, 2012. | This Internet-Draft will expire on November 2, 2012. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2012 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 | |||
skipping to change at page 2, line 22 | skipping to change at page 2, line 22 | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Signaling DNSSEC Algorithm Understood (DAU), DS Hash | 2. Signaling DNSSEC Algorithm Understood (DAU), DS Hash | |||
Understood (DHU) and NSEC3 Hash Understood (N3U) Using EDNS . . 3 | Understood (DHU) and NSEC3 Hash Understood (N3U) Using EDNS . . 3 | |||
3. Client Considerations . . . . . . . . . . . . . . . . . . . . . 5 | 3. Client Considerations . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . . 5 | 3.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.2. Validating Stub Resolvers . . . . . . . . . . . . . . . . . 5 | 3.1.1. Validating Stub Resolvers . . . . . . . . . . . . . . . 5 | |||
3.3. Non-Validating Stub Resolvers . . . . . . . . . . . . . . . 5 | 3.1.2. Non-Validating Stub Resolvers . . . . . . . . . . . . . 5 | |||
3.4. Recursive Resolvers . . . . . . . . . . . . . . . . . . . . 5 | 3.2. Recursive Resolvers . . . . . . . . . . . . . . . . . . . . 5 | |||
3.4.1. Validating Recursive Resolvers . . . . . . . . . . . . 5 | 3.2.1. Validating Recursive Resolvers . . . . . . . . . . . . 5 | |||
3.4.2. Non-validating Recursive Resolvers . . . . . . . . . . 6 | 3.2.2. Non-validating Recursive Resolvers . . . . . . . . . . 6 | |||
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 . . . . . . . . . . . . . . . . . . . . . . 7 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 | |||
skipping to change at page 3, line 14 | skipping to change at page 3, line 14 | |||
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. | was used to generate the digital signature. | |||
Likewise, Delegated Signer (DS) RR's and NSEC3 RR's use a hashed | Likewise, Delegation Signer (DS) RR's and NSEC3 RR's use a hashed | |||
value as part of their RDATA and like digital signature algorithms, | value as part of their RDATA and, like digital signature algorithms, | |||
these hash algorithms have code numbers. All three algorithm codes | these hash algorithms have code numbers. All three algorithm codes | |||
(RRSIG/DNSKEY, DS and NSEC3) are maintained in unique IANA | (RRSIG/DNSKEY, DS and NSEC3) are maintained in unique IANA | |||
registries. | registries. | |||
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 in a DNS query which digital signature | |||
they support in a DNS query. This is done using the EDNS attribute | and/or hash algorithms they support. This is done using the new EDNS | |||
values in the OPT meta-RR [RFC2671]. | options specified below in Section 2 for use in the OPT meta-RR | |||
[I-D.ietf-dnsext-rfc2671bis-edns0]. | ||||
These proposed EDNS options serve to measure the acceptance and use | These proposed EDNS options serve to measure the acceptance and use | |||
of new digital signing algorithms. These signaling options can be | of new digital signing algorithms. These signaling options can be | |||
used by zone administrators as a gauge to measure the successful | used by zone administrators as a gauge to measure the successful | |||
deployment of code that implements a newly deployed digital signature | deployment of code that implements a newly deployed digital signature | |||
and hash algorithm, DS hash and NSEC3 hash algorithm used with | algorithm, DS hash and NSEC3 hash algorithm used with DNSSEC. A zone | |||
DNSSEC. A zone administrator may be able to determine when to stop | administrator may be able to determine when to stop signing with a | |||
signing with the old algorithm(s) when the server sees that a | superseded algorithm when the server sees that a significant number | |||
significant number of its clients signal that they are able to accept | of its clients signal that they are able to accept the new algorithm. | |||
the new algorithm. Note that this survey may be conducted over the | Note that this survey may be conducted over the period of years | |||
period of years before a tipping point is seen. | before a tipping point is seen. | |||
This draft does not seek to introduce another process for including | This draft does not seek to introduce another process for including | |||
new algorithms for use with DNSSEC. It also does not address the | new algorithms for use with DNSSEC. 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 and hashes it implements. | query can signal a set of algorithms and hashes it implements. | |||
2. Signaling DNSSEC Algorithm Understood (DAU), DS Hash Understood | 2. Signaling DNSSEC Algorithm Understood (DAU), DS Hash Understood | |||
(DHU) and NSEC3 Hash Understood (N3U) Using EDNS | (DHU) and NSEC3 Hash Understood (N3U) Using EDNS | |||
The ENDS0 specification outlined in [RFC2671] defines a way to | The ENDS0 specification outlined in | |||
include new options using a standardized mechanism. These options | [I-D.ietf-dnsext-rfc2671bis-edns0] defines a way to include new | |||
are contained in the RDATA of the OPT meta-RR. This document defines | options using a standardized mechanism. These options are contained | |||
three new EDNS0 options for a client to signal which digital | in the RDATA of the OPT meta-RR. This document defines three new | |||
signature and/or hash algorithms the client supports. These options | EDNS options for a client to signal which digital signature and/or | |||
can be used independly of each other and MAY appear in any order in | hash algorithms the client supports. These options can be used | |||
the OPT RR. | independently of each other and MAY appear in any order in the OPT | |||
RR. | ||||
The figure below shows how each option is defined in the RDATA of the | The figure below shows how each option is defined in the RDATA of the | |||
OPT RR specified in [RFC2671]: | OPT RR specified in [I-D.ietf-dnsext-rfc2671bis-edns0]: | |||
0 8 16 | 0 8 16 | |||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |||
| OPTION-CODE (TBD) | | | OPTION-CODE (TBD) | | |||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |||
| LIST-LENGTH | | | LIST-LENGTH | | |||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |||
| ALG-CODE | ... \ | | ALG-CODE | ... \ | |||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |||
skipping to change at page 4, line 29 | skipping to change at page 4, line 31 | |||
o DNSSEC Algorithm Understood (DAU) option for DNSSEC digital | o DNSSEC Algorithm Understood (DAU) option for DNSSEC digital | |||
signing algorithms. Its value is fixed at TBD1. | signing algorithms. Its value is fixed at TBD1. | |||
o DS Hash Understood (DHU) option for DS RR hash algorithms. Its | o DS Hash Understood (DHU) option for DS RR hash algorithms. Its | |||
value is fixed at TBD2. | value is fixed at TBD2. | |||
o NSEC3 Hash Understood (N3U) option for NSEC3 hash algorithms. Its | o NSEC3 Hash Understood (N3U) option for NSEC3 hash algorithms. Its | |||
value is fixed at TBD3. | value is fixed at TBD3. | |||
LIST-LENGTH is the length of the list of digital signature or hash | LIST-LENGTH is the length of the list of digital signature or hash | |||
algorithms in octets. Since each algorithm and hash codes are 1 | algorithm codes in octets. Each algorithm code occupies a single | |||
octet long so this value is the number of octets. | octet. | |||
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, DS hash algorithms, or NSEC3 hash algorithms (depending | algorithms, DS hash algorithms, or NSEC3 hash algorithms (depending | |||
on the OPTION-CODE in use) that the client indicates as understood. | on the OPTION-CODE in use) that the client declares to be supported. | |||
The values SHOULD be in descending order of preference, with the most | The values SHOULD be in descending order of preference, with the most | |||
preferred algorithm first. For example, if a validating client | preferred algorithm first. For example, if a validating client | |||
signals the DAU option and RSA/SHA-1, RSA/SHA-256 and prefers the | signals the DAU option and RSA/SHA-1, RSA/SHA-256 and prefers the | |||
latter, the values of ALG-CODE would be: 8 (RSA/SHA-256), 5 (RSA/ | latter, the values of ALG-CODE would be: 8 (RSA/SHA-256), 5 (RSA/ | |||
SHA-1). | SHA-1). | |||
If all three options are included in the OPT RR, there is a potential | If all three options are included in the OPT RR, there is a potential | |||
for the OPT RR to take up considerable size in the DNS message. | for the OPT RR to take up considerable size in the DNS message. | |||
However, in practical terms including all three options are likely to | However, in practical terms, including all three options is likely to | |||
take up 16-24 octets (average of 6-10 digital signature algorithms, | take up 22-34 octets (average of 6-10 digital signature algorithms, | |||
3-5 DS hash algorithms and 1-5 NSEC3 hash algorithms) including the | 3-5 DS hash algorithms and 1-5 NSEC3 hash algorithms) including the | |||
EDNS option codes and option lengths in a reasonable potential future | EDNS option codes and option lengths in a reasonable potential future | |||
example. | example. | |||
3. Client Considerations | 3. Client Considerations | |||
A validating end-system resolver sets the DAU, DHU and/or N3U option, | A validating end-system resolver sets the DAU, DHU and/or N3U option, | |||
or combination thereof in the OPT meta-RR when sending a query. The | or combination thereof in the OPT meta-RR when sending a query. The | |||
validating end-system resolver sets the value(s) in the order of | validating end-system resolver sets the value(s) in the order of | |||
preference, with the most preferred algorithm(s) first as described | preference, with the most preferred algorithm(s) first as described | |||
in section 2. The end-system resolver SHOULD also set the DNSSEC-OK | in section 2. The end-system resolver SHOULD also set the DNSSEC-OK | |||
bit [RFC4035] to indicate that it wishes to receive DNSSEC RRs in the | bit [RFC4035] to indicate that it wishes to receive DNSSEC RRs in the | |||
response. | response. | |||
Note that the PRIVATEDNS (253) and/or the PRIVATEOID (254) digital | Note that the PRIVATEDNS (253) and/or the PRIVATEOID (254) digital | |||
signature codes for cover a potentially wide range of algorithms and | signature codes both cover a potentially wide range of algorithms and | |||
are likely not useful to a server. There is no compelling reason for | are likely not useful to a server. There is no compelling reason for | |||
a client to include these codes in its list of the DAU. Likewise, | a client to include these codes in its list of the DAU. Likewise, | |||
clients MUST NOT include RESERVED codes in any of the options. | clients MUST NOT include RESERVED codes in any of the options. | |||
3.1. Stub Resolvers | 3.1. Stub Resolvers | |||
Typically, stub resolvers rely on an upstream recursive server (or | Typically, stub resolvers rely on an upstream recursive server (or | |||
cache) to provide a response. So optimal setting of the DAU, DSU and | cache) to provide a response. So optimal setting of the DAU, DSU and | |||
N3U options depends on whether the stub resolver performs its own | N3U options depends on whether the stub resolver elects to perform | |||
DNSSEC validation or doesn't perform its own validation. | its own validation. | |||
3.2. Validating Stub Resolvers | 3.1.1. Validating Stub Resolvers | |||
A validating stub resolver already (usually) sets the DO bit | A validating stub resolver already (usually) sets the DO bit | |||
[RFC4035] to indicate that it wishes to receive additional DNSSEC RRs | [RFC4035] to indicate that it wishes to receive additional DNSSEC RRs | |||
(i.e. RRSIG RR's) in the response. Such validating resolvers SHOULD | (i.e. RRSIG RR's) in the response. Such validating resolvers SHOULD | |||
include the DAU, DHU and/or the N3U option(s) in the OPT RR when | include the DAU, DHU and/or the N3U option(s) in the OPT RR when | |||
sending a query. This way thee validating stub resolver indicates | sending a query. This way the validating stub resolver indicates | |||
which cryptographic algorithm(s) it supports by setting the values(s) | which cryptographic algorithm(s) it supports by setting the values in | |||
in the order of preference, with the most preferred algorithm(s) | the order of preference, with the most preferred algorithm first as | |||
first as described in Section 2. | described in Section 2. | |||
3.3. Non-Validating Stub Resolvers | 3.1.2. Non-Validating Stub Resolvers | |||
The DAU, DHU and N3U EDNS options are NOT RECOMMENDED for non- | The DAU, DHU and N3U EDNS options are NOT RECOMMENDED for non- | |||
validating stub resolvers. | validating stub resolvers. | |||
3.4. Recursive Resolvers | 3.2. Recursive Resolvers | |||
3.4.1. Validating Recursive Resolvers | 3.2.1. Validating Recursive Resolvers | |||
A validating recursive resolver sets the DAU, DHU and/or N3U | A validating recursive resolver sets the DAU, DHU and/or N3U | |||
option(s) when performing recursion based on the DO and CD flags in | option(s) when performing recursion based on the DO and CD flags in | |||
the client request [RFC4035]. If the client of the recursive | the client request [RFC4035]. If the client of the recursive | |||
resolver did not include the DO bit in the query the recursive | resolver did not include the DO bit in the query the recursive | |||
resolver SHOULD include the option(s) according to its own local | resolver SHOULD include the option(s) according to its own local | |||
policy. | policy. | |||
If the client did include the DO and CD bits, but did not include the | If the client did include the DO and CD bits, but did not include the | |||
DAU, DHU and/or N3U option(s) in the query, the validating recursive | DAU, DHU and/or N3U option(s) in the query, the validating recursive | |||
skipping to change at page 6, line 19 | skipping to change at page 6, line 19 | |||
If the client did set the DO bit and the option(s) in the query, the | If the client did set the DO bit and the option(s) in the query, the | |||
validating recursive resolver SHOULD include the option(s) based on | validating recursive resolver SHOULD include the option(s) based on | |||
the setting of the CD bit. If the CD bit is set, the validating | the setting of the CD bit. If the CD bit is set, the validating | |||
recursive resolver SHOULD include the option(s) based on the client | recursive resolver SHOULD include the option(s) based on the client | |||
query or a superset of the client option(s) list and the validator's | query or a superset of the client option(s) list and the validator's | |||
own list (if different). If the CD bit is not set, the validating | own list (if different). If the CD bit is not set, the validating | |||
recursive resolver MAY copy the client option(s) or substitute its | recursive resolver MAY copy the client option(s) or substitute its | |||
own option list. | own option list. | |||
3.4.2. Non-validating Recursive Resolvers | 3.2.2. Non-validating Recursive Resolvers | |||
Recursive resolvers that do not do validation SHOULD copy the DAU, | Recursive resolvers that do not do validation SHOULD copy the DAU, | |||
DHU and/or N3U option(s) seen in received queries as they represent | DHU and/or N3U option(s) seen in received queries as they represent | |||
the wishes of the validating downstream resolver that issued the | the wishes of the validating downstream resolver that issued the | |||
original query. | original query. | |||
4. Intermediate System Considerations | 4. Intermediate System Considerations | |||
Intermediate proxies [RFC5625] that understand DNS SHOULD behave like | Intermediate proxies [RFC5625] that understand DNS SHOULD behave like | |||
a comparable recursive resolver when dealing with the DAU, DHU and | a comparable recursive resolver when dealing with the DAU, DHU and | |||
N3U options. | N3U options. | |||
5. Server Considerations | 5. Server Considerations | |||
When an authoritative server sees the DAU, DHU and/or N3U option(s) | When an authoritative server sees the DAU, DHU and/or N3U option(s) | |||
in the OPT meta-RR in a request the normal algorithm for servicing | in the OPT meta-RR in a request the normal algorithm for servicing | |||
requests is followed. The options does not trigger any special | requests is followed. The options MUST NOT trigger any special | |||
processing on the server side. | processing (e.g. RRSIG filtering in responses) on the server side. | |||
If the options are present but the DNSSEC-OK (OK) bit is not set, the | If the options are present but the DNSSEC-OK (OK) bit is not set, the | |||
server does not do any DNSSEC processing, including any recording of | server does not do any DNSSEC processing, including any recording of | |||
the option(s). | the option(s). | |||
6. Traffic Analysis Considerations | 6. Traffic Analysis Considerations | |||
Zone administrators that are planning or are in the process of a | Zone administrators that are planning or are in the process of a | |||
cryptographic algorithm rollover operation should monitor DNS query | cryptographic algorithm rollover operation should monitor DNS query | |||
traffic and record the number of queries, the presense of the OPT RR | traffic and record the number of queries, the presense of the OPT RR | |||
in queries and the values of the DAU/DHU/N3U option(s) (if present). | in queries and the values of the DAU/DHU/N3U option(s) (if present). | |||
This monitoring can be used to measure the deployment of client code | This monitoring can be used to measure the deployment of client code | |||
that implements (and signals) certain algorithms. The Exactly how to | that implements (and signals) specific algorithms. Description of | |||
capture DNS traffic and measure new algorithm adoption is beyond the | the techniques used to capture DNS traffic and measure new algorithm | |||
scope of this document. | adoption is beyond the scope of this document. | |||
Zone administrators that need to comply with changes to their | Zone administrators that need to comply with changes to their | |||
organization's security policy (with regards to cryptographic | organization's security policy (with regards to cryptographic | |||
algorithm use) can use this data to set milestone dates for | algorithm use) can use this data to set milestone dates for | |||
performing an algorithm rollover. For example, zone administrators | performing an algorithm rollover. For example, zone administrators | |||
can use the data to determine when older algorithms can be phased out | can use the data to determine when older algorithms can be phased out | |||
without disrupting a significant number of clients. In order to keep | without disrupting a significant number of clients. In order to keep | |||
this disruption to a minimum, zone administrators should wait to | this disruption to a minimum, zone administrators should wait to | |||
complete an algorithm rollover until a large majority of clients | complete an algorithm rollover until a large majority of clients | |||
signal that they understand the new algorithm. This may be in the | signal that they recognize the new algorithm. This may be in the | |||
order of years rather than months. Note that clients that do not | order of years rather than months. | |||
implement these options are likely to be older implementations which | ||||
would also not implement any newly deployed algorithm. | Note that clients that do not implement these options are likely to | |||
be older implementations which would also not implement any newly | ||||
deployed algorithm. | ||||
7. IANA Considerations | 7. IANA Considerations | |||
The algorithm codes used to identify DNSSEC algorithms, DS RR hash | The algorithm codes used to identify DNSSEC algorithms, DS RR hash | |||
algorithms and NSEC3 hash algorithms have already been established by | algorithms and NSEC3 hash algorithms have already been established by | |||
IANA. This document does not seek to alter that registry in any way. | IANA. This document does not seek to alter that registry in any way. | |||
This draft seeks to update the "DNS EDNS0 Options" registry by adding | This draft seeks to update the "DNS EDNS Options" registry by adding | |||
the DAU, DHU and N3U options and referencing this document. The code | the DAU, DHU and N3U options and referencing this document. The code | |||
for these options are TBD1, TBD2 and TBD3 respectively. | for these options are TBD1, TBD2 and TBD3 respectively. | |||
8. Security Considerations | 8. Security Considerations | |||
This document specifies a way for a client to signal its | This document specifies a way for a client to signal its | |||
cryptographic and hash algorithm knowledge to a cache or server. It | cryptographic and hash algorithm knowledge to a cache or server. It | |||
is not meant to be a discussion on algorithm superiority. The | is not meant to be a discussion on algorithm superiority. The | |||
signals are optional codes contained in the OPT meta-RR used with | signals are optional codes contained in the OPT meta-RR used with | |||
EDNS0. The goal of these options are to signal new algorithm uptake | EDNS. The goal of these options are to signal new algorithm uptake | |||
in client code to allow zone administrators to know when it is | in client code to allow zone administrators to know when it is | |||
possible to complete an algorithm rollover in a DNSSEC signed zone. | possible to complete an algorithm rollover in a DNSSEC signed zone. | |||
9. Normative References | 9. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [I-D.ietf-dnsext-rfc2671bis-edns0] Damas, J., Graff, M., and P. | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Vixie, "Extension Mechanisms for | |||
DNS (EDNS0)", draft-ietf-dnsext- | ||||
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", | rfc2671bis-edns0-08 (work in | |||
RFC 2671, August 1999. | progress), February 2012. | |||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC2119] Bradner, S., "Key words for use | |||
Rose, "DNS Security Introduction and Requirements", | in RFCs to Indicate Requirement | |||
RFC 4033, March 2005. | Levels", BCP 14, RFC 2119, | |||
March 1997. | ||||
[RFC4034] 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 4033, | ||||
March 2005. | ||||
Rose, "Resource Records for the DNS Security Extensions", | [RFC4034] Arends, R., Austein, R., Larson, | |||
RFC 4034, March 2005. | M., Massey, D., and S. Rose, | |||
"Resource Records for the DNS | ||||
Security Extensions", RFC 4034, | ||||
March 2005. | ||||
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4035] Arends, R., Austein, R., Larson, | |||
Rose, "Protocol Modifications for the DNS Security | M., Massey, D., and S. Rose, | |||
Extensions", RFC 4035, March 2005. | "Protocol Modifications for the | |||
DNS Security Extensions", | ||||
RFC 4035, March 2005. | ||||
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", | [RFC5625] Bellis, R., "DNS Proxy | |||
BCP 152, RFC 5625, August 2009. | Implementation Guidelines", | |||
BCP 152, RFC 5625, August 2009. | ||||
Authors' Addresses | Authors' Addresses | |||
Steve Crocker | Steve Crocker | |||
Shinkuro Inc. | Shinkuro Inc. | |||
5110 Edgemoor Lane | 5110 Edgemoor Lane | |||
Bethesda, MD 20814 | Bethesda, MD 20814 | |||
USA | USA | |||
EMail: steve@shinkuro.com | EMail: steve@shinkuro.com | |||
End of changes. 31 change blocks. | ||||
72 lines changed or deleted | 87 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/ |