draft-ietf-dnsext-dnssec-algo-signal-01.txt   draft-ietf-dnsext-dnssec-algo-signal-02.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: October 1, 2011 NIST Expires: January 7, 2012 NIST
March 30, 2011 July 6, 2011
Signaling Cryptographic Algorithm Understanding in DNSSEC Signaling Cryptographic Algorithm Understanding in DNSSEC
draft-ietf-dnsext-dnssec-algo-signal-01 draft-ietf-dnsext-dnssec-algo-signal-02
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 October 1, 2011. This Internet-Draft will expire on January 7, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . 6
4. Intermediate Middlebox 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
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7
skipping to change at page 3, line 35 skipping to change at page 3, line 35
option can be used by zone administrators as a gauge to measure the option can be used by zone administrators as a gauge to measure the
successful deployment of code that implements a newly deployed successful deployment of code that implements a newly deployed
digital signature or hash algorithm used with DNSSEC. A zone digital signature or hash algorithm used with DNSSEC. A zone
administrator may be able to determine when to stop serving the old administrator may be able to determine when to stop serving the old
algorithm when the server sees that a significant number of its algorithm when the server sees that a significant number of its
clients signal that they are able to accept the new algorithm. Note clients signal that they are able to accept the new algorithm. Note
that this survey may be conducted over the period of years before a that this survey may be conducted 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. 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
skipping to change at page 4, line 29 skipping to change at page 4, line 29
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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 it understands. 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 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 octets. DNSSEC DS hash codes are 1 octet long so this value is the
number of octets. number of octets.
HASH-CODE is the list of assigned values of DNSSEC DS hash algorithms HASH-CODE is the list of assigned values of DNSSEC DS hash algorithms
skipping to change at page 5, line 14 skipping to change at page 5, line 14
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
cover a potentially wide range of algorithms and are likely not cover a potentially wide range of algorithms and are likely not
useful to a server. There is no compelling reason for a client to useful to a server. There is no compelling reason for a client to
include these codes in its list of understood algorithms. include these codes in its list of understood algorithms.
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; any algorithm support on the stub cache) to provide a response. So optimal setting of the DAU option
resolver's side SHOULD be honored (if possible) by an upstream depends on whether the stub resolver performs its own DNSSEC
recursive cache. validation or doesn't perform its own validation.
3.2. Validating Stub Resolvers 3.2. Validating Stub Resolvers
A validating stub resolver MUST set the DO bit [RFC4035] to indicate A validating stub resolver already (usually) sets the DO bit
that it wishes to receive DNSSEC RRs in the response. Such [RFC4035] to indicate that it wishes to receive additional DNSSEC RRs
validating resolvers SHOULD include the DAU option in the OPT RR when (i.e. RRSIG RR's) in the response. Such validating resolvers SHOULD
sending a query. This way the validating stub resolver indicates include the DAU option in the OPT RR when sending a query. This way
which cryptographic algorithm(s) it supports by setting the values(s) thee validating stub resolver indicates which cryptographic
in the order of preference, with the most preferred algorithm(s) algorithm(s) it supports by setting the values(s) in the order of
first as described in Section 2. preference, with the most preferred algorithm(s) first as described
in Section 2.
3.3. Non-Validating Stub Resolvers 3.3. Non-Validating Stub Resolvers
The DAU EDNS option is NOT RECOMMENDED for non-validating stub The DAU EDNS option is NOT RECOMMENDED for non-validating stub
resolvers. resolvers.
3.4. Recursive Resolvers 3.4. Recursive Resolvers
3.4.1. Validating Recursive Resolvers 3.4.1. Validating Recursive Resolvers
A validating recursive resolver MUST set the DO bit [RFC4035] to A validating recursive resolver sets the DAU option when performing
indicate that it wishes to receive DNSSEC RRs in the response. If recursion based on the DO and CD flags in the client request
the client of the recursive resolver did not include the DO bit in [RFC4035]. If the client of the recursive resolver did not include
the query the recursive resolver SHOULD include the DAU option the DO bit in the query the recursive resolver SHOULD include the DAU
according to its own local policy. option according to its own local 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 option in the query, the validating recursive resolver SHOULD NOT DAU option in the query, the validating recursive resolver SHOULD NOT
include the DAU option to avoid conflicts. include the DAU option to avoid conflicts.
If the client did set the DO bit and the DAU option in the query, the If the client did set the DO bit and the DAU option in the query, the
validating recursive resolver SHOULD include the DAU option based on validating recursive resolver SHOULD include the DAU option 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 DAU option based on the client recursive resolver SHOULD include the DAU option based on the client
query or a superset of the client DAU option list and the validator's query or a superset of the client DAU option 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 DAU option or substitute its recursive resolver MAY copy the client DAU option or substitute its
own DAU option list. own DAU option list.
3.4.2. Non-validating Recursive Resolvers 3.4.2. Non-validating Recursive Resolvers
Recursive resolvers that do not do validation or caching SHOULD copy Recursive resolvers that do not do validation or caching SHOULD copy
the DAU option seen in received queries as they represent the wishes the DAU option seen in received queries as they represent the wishes
of the validating downstream resolver that issued the original query. of the validating downstream resolver that issued the original query.
4. Intermediate Middlebox Considerations 4. Intermediate System Considerations
Intermediate middleboxes SHOULD behave like a comparable recursive Intermediate proxies [RFC5625] that understand DNS SHOULD behave like
resolver when dealing with the DAU option [RFC5625]. a comparable recursive resolver when dealing with the DAU option.
5. Server Considerations 5. Server Considerations
When an authoritative server sees the DAU option in the OPT meta-RR When an authoritative server sees the DAU option in the OPT meta-RR
in a request the normal algorithm for servicing requests is followed. in a request the normal algorithm for servicing requests is followed.
The DAU option does not trigger any special processing on the server The DAU option does not trigger any special processing on the server
side. side.
If the DAU option is present but the DNSSEC-OK (OK) bit is not set, If the DAU option is present but the DNSSEC-OK (OK) bit is not set,
the server does not do any DNSSEC processing, including any recording the server does not do any DNSSEC processing, including any recording
 End of changes. 11 change blocks. 
25 lines changed or deleted 26 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/