draft-ietf-dnsext-dnssec-algo-signal-04.txt | draft-ietf-dnsext-dnssec-algo-signal-05.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 7, 2012 NIST | Expires: September 27, 2012 NIST | |||
March 6, 2012 | March 26, 2012 | |||
Signaling Cryptographic Algorithm Understanding in DNSSEC | Signaling Cryptographic Algorithm Understanding in DNSSEC | |||
draft-ietf-dnsext-dnssec-algo-signal-04 | draft-ietf-dnsext-dnssec-algo-signal-05 | |||
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 7, 2012. | This Internet-Draft will expire on September 27, 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 6, line 47 | skipping to change at page 6, line 47 | |||
processing on the server side. | processing 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 values of the DAU/DHU/N3U option(s) in | traffic and record the number of queries, the presense of the OPT RR | |||
queries. This monitoring can measure the deployment of client code | in queries and the values of the DAU/DHU/N3U option(s) (if present). | |||
that implements (and signals) certain algorithms. Exactly how to | This monitoring can be used to measure the deployment of client code | |||
that implements (and signals) certain algorithms. The Exactly how to | ||||
capture DNS traffic and measure new algorithm adoption is beyond the | capture DNS traffic and measure new algorithm adoption is beyond the | |||
scope of this document. | scope of this document. | |||
Zone administrators can use this data to set plans for starting an | Zone administrators that need to comply with changes to their | |||
algorithm rollover and determine when older algorithms can be phased | organization's security policy (with regards to cryptographic | |||
out without disrupting a significant number of clients. In order to | algorithm use) can use this data to set milestone dates for | |||
keep this disruption to a minimum, zone administrators should wait to | performing an algorithm rollover. For example, zone administrators | |||
can use the data to determine when older algorithms can be phased out | ||||
without disrupting a significant number of clients. In order to keep | ||||
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 understand 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. Note that clients that do not | |||
implement these options are likely to be older implementations which | implement these options are likely to be older implementations which | |||
would also not implement any newly deployed algorithm. | 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 | |||
End of changes. 5 change blocks. | ||||
11 lines changed or deleted | 15 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/ |