idnits 2.17.1 draft-ietf-dnsext-dnssec-algo-signal-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (March 30, 2011) is 4747 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions Working Group S. Crocker 3 Internet-Draft Shinkuro Inc. 4 Intended status: Standards Track S. Rose 5 Expires: October 1, 2011 NIST 6 March 30, 2011 8 Signaling Cryptographic Algorithm Understanding in DNSSEC 9 draft-ietf-dnsext-dnssec-algo-signal-01 11 Abstract 13 The DNS Security Extensions (DNSSEC) were developed to provide origin 14 authentication and integrity protection for DNS data by using digital 15 signatures. These digital signatures can be generated using 16 different algorithms. This draft sets out to specify a way for 17 validating end-system resolvers to signal to a server which 18 cryptographic algorithms they support. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 1, 2011. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Signaling DNSSEC Algorithm Understood (DAU) Using EDNS . . . . 3 64 3. Client Considerations . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. Validating Stub Resolvers . . . . . . . . . . . . . . . . . 5 67 3.3. Non-Validating Stub Resolvers . . . . . . . . . . . . . . . 5 68 3.4. Recursive Resolvers . . . . . . . . . . . . . . . . . . . . 5 69 3.4.1. Validating Recursive Resolvers . . . . . . . . . . . . 5 70 3.4.2. Non-validating Recursive Resolvers . . . . . . . . . . 6 72 4. Intermediate Middlebox Considerations . . . . . . . . . . . . . 6 74 5. Server Considerations . . . . . . . . . . . . . . . . . . . . . 6 76 6. Traffic Analysis Considerations . . . . . . . . . . . . . . . . 6 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 82 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 84 1. Introduction 86 The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034] and 87 [RFC4035] were developed to provide origin authentication and 88 integrity protection for DNS data by using digital signatures. Each 89 digital signature RR (RRSIG) contains an algorithm code number. 90 These algorithm codes tells validators which cryptographic algorithm 91 was used to generate the digital signature. Authentication across 92 delegation boundaries is maintained by storing a hash of a subzone's 93 key in the parent zone stored in a Delegation Signer (DS) RR. These 94 DS RR's contain a second code number to identify the hash algorithm 95 used to construct the DS RR. 97 This draft sets out to specify a way for validating end-system 98 resolvers to tell a server which cryptographic and/or hash algorithms 99 they support in a DNS query. This is done using the EDNS attribute 100 values in the OPT meta-RR [RFC2671]. 102 This proposed EDNS option serves to measure the acceptance and use of 103 new digital signing and hash algorithms. This algorithm signaling 104 option can be used by zone administrators as a gauge to measure the 105 successful deployment of code that implements a newly deployed 106 digital signature or hash algorithm used with DNSSEC. A zone 107 administrator may be able to determine when to stop serving the old 108 algorithm when the server sees that a significant number of its 109 clients signal that they are able to accept the new algorithm. Note 110 that this survey may be conducted over the period of years before a 111 tipping point is seen. 113 This draft does not seek to include another process for including new 114 algorithms for use with DNSSEC. It also does not address the 115 question of which algorithms are to be included in any official list 116 of mandatory or recommended cryptographic algorithms for use with 117 DNSSEC. Rather, this document specifies a means by which a client 118 query can signal a set of algorithms it implements. 120 2. Signaling DNSSEC Algorithm Understood (DAU) Using EDNS 122 The ENDS0 specification outlined in [RFC2671] defines a way to 123 include new options using a standardized mechanism. These options 124 are contained in the RDATA of the OPT meta-RR. This document defines 125 a new EDNS0 option for a client to signal which algorithms the client 126 supports. 128 The figure below shows how the signaling attribute is defined in the 129 RDATA of the OPT RR specified in [RFC2671]: 131 0 8 16 132 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 133 | OPTION-CODE (TBD) | 134 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 135 | DIGITAL-SIG-LIST-LENGTH | 136 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 137 | ALG-CODE | ... \ 138 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 139 | DS-HASH-LIST-LENGTH | 140 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 141 | HASH-CODE | ... \ 142 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 144 OPTION-CODE is the code for the DNSSEC Algorithm Understood (DAU) 145 option. Its value is fixed at TBD. 147 DIGITAL-SIG-LIST-LENGTH is the length of the list of digital 148 signature algorithms in octets. DNSSEC algorithm codes are 1 octet 149 long so this value is the number of octets. 151 ALG-CODE is the list of assigned values of DNSSEC zone signing 152 algorithms that the client indicates it understands. The values 153 SHOULD be in descending order of preference, with the most preferred 154 algorithm first. For example, if a validating client implements RSA/ 155 SHA-1, RSA/SHA-256 and prefers the latter, the value of ALG-CODE 156 would be: 8 (RSA/SHA-256), 5 (RSA/SHA-1). 158 DS-HASH-LIST-LENGTH is the length of the list of hash algorithms in 159 octets. DNSSEC DS hash codes are 1 octet long so this value is the 160 number of octets. 162 HASH-CODE is the list of assigned values of DNSSEC DS hash algorithms 163 that the client indicates as understood. Like the ALG-CODE above, 164 the values SHOULD be in descending order of preference, with the most 165 preferred algorithm first. 167 3. Client Considerations 169 A validating end-system resolver sets the DAU option in the OPT 170 meta-RR when sending a query. The validating end-system resolver 171 sets the value(s) in the order of preference, with the most preferred 172 algorithm(s) first as described in section 2. The end-system 173 resolver SHOULD also set the DNSSEC-OK bit [RFC4035] to indicate that 174 it wishes to receive DNSSEC RRs in the response. 176 Note that the PRIVATEDNS (253) and/or the PRIVATEOID (254) codes 177 cover a potentially wide range of algorithms and are likely not 178 useful to a server. There is no compelling reason for a client to 179 include these codes in its list of understood algorithms. 181 3.1. Stub Resolvers 183 Typically, stub resolvers rely on an upstream recursive server (or 184 cache) to provide a response; any algorithm support on the stub 185 resolver's side SHOULD be honored (if possible) by an upstream 186 recursive cache. 188 3.2. Validating Stub Resolvers 190 A validating stub resolver MUST set the DO bit [RFC4035] to indicate 191 that it wishes to receive DNSSEC RRs in the response. Such 192 validating resolvers SHOULD include the DAU option in the OPT RR when 193 sending a query. This way the validating stub resolver indicates 194 which cryptographic algorithm(s) it supports by setting the values(s) 195 in the order of preference, with the most preferred algorithm(s) 196 first as described in Section 2. 198 3.3. Non-Validating Stub Resolvers 200 The DAU EDNS option is NOT RECOMMENDED for non-validating stub 201 resolvers. 203 3.4. Recursive Resolvers 205 3.4.1. Validating Recursive Resolvers 207 A validating recursive resolver MUST set the DO bit [RFC4035] to 208 indicate that it wishes to receive DNSSEC RRs in the response. If 209 the client of the recursive resolver did not include the DO bit in 210 the query the recursive resolver SHOULD include the DAU option 211 according to its own local policy. 213 If the client did include the DO and CD bits, but did not include the 214 DAU option in the query, the validating recursive resolver SHOULD NOT 215 include the DAU option to avoid conflicts. 217 If the client did set the DO bit and the DAU option in the query, the 218 validating recursive resolver SHOULD include the DAU option based on 219 the setting of the CD bit. If the CD bit is set, the validating 220 recursive resolver SHOULD include the DAU option based on the client 221 query or a superset of the client DAU option list and the validator's 222 own list (if different). If the CD bit is not set, the validating 223 recursive resolver MAY copy the client DAU option or substitute its 224 own DAU option list. 226 3.4.2. Non-validating Recursive Resolvers 228 Recursive resolvers that do not do validation or caching SHOULD copy 229 the DAU option seen in received queries as they represent the wishes 230 of the validating downstream resolver that issued the original query. 232 4. Intermediate Middlebox Considerations 234 Intermediate middleboxes SHOULD behave like a comparable recursive 235 resolver when dealing with the DAU option [RFC5625]. 237 5. Server Considerations 239 When an authoritative server sees the DAU option in the OPT meta-RR 240 in a request the normal algorithm for servicing requests is followed. 241 The DAU option does not trigger any special processing on the server 242 side. 244 If the DAU option is present but the DNSSEC-OK (OK) bit is not set, 245 the server does not do any DNSSEC processing, including any recording 246 of the DAU option. 248 6. Traffic Analysis Considerations 250 Zone administrators that are planning or are in the process of a 251 cryptographic algorithm rollover operation should monitor DNS query 252 traffic and record the values of the DAU option in queries. This 253 monitoring can measure the deployment of client code that implements 254 (and signals) certain algorithms. Exactly how to capture DNS traffic 255 and measure new algorithm adoption is beyond the scope of this 256 document. 258 Zone administrators can use this data to set plans for starting an 259 algorithm rollover and determine when older algorithms can be phased 260 out without disrupting a significant number of clients. In order to 261 keep this disruption to a minimum, zone administrators should wait to 262 complete an algorithm rollover until a large majority of clients 263 signal that they understand the new algorithm. This may be in the 264 order of years rather than months. Note that clients that do not 265 implement the DAU option are likely to be older implementations which 266 would also not implement any newly deployed algorithm. 268 7. IANA Considerations 270 The algorithm codes used to identify DNSSEC algorithms has already 271 been established by IANA. This document does not seek to alter that 272 registry in any way. 274 This draft seeks to update the "DNS EDNS0 Options" registry by adding 275 the DAU option and referencing this document. The code for the 276 option should be TBD. 278 8. Security Considerations 280 This document specifies a way for a client to signal its digital 281 signature algorithm preference to a cache or server. It is not meant 282 to be a discussion on algorithm superiority. The signal is an 283 optional code contained in the OPT meta-RR used with EDNS0. The goal 284 of this option is to signal new algorithm uptake in client code to 285 allow zone administrators to know when it is possible to complete an 286 algorithm rollover in a DNSSEC signed zone. 288 9. Normative References 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, March 1997. 293 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 294 RFC 2671, August 1999. 296 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 297 Rose, "DNS Security Introduction and Requirements", 298 RFC 4033, March 2005. 300 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 301 Rose, "Resource Records for the DNS Security Extensions", 302 RFC 4034, March 2005. 304 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 305 Rose, "Protocol Modifications for the DNS Security 306 Extensions", RFC 4035, March 2005. 308 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 309 BCP 152, RFC 5625, August 2009. 311 Authors' Addresses 313 Steve Crocker 314 Shinkuro Inc. 315 5110 Edgemoor Lane 316 Bethesda, MD 20814 317 USA 319 EMail: steve@shinkuro.com 321 Scott Rose 322 NIST 323 100 Bureau Dr. 324 Gaithersburg, MD 20899 325 USA 327 Phone: +1-301-975-8439 328 EMail: scottr.nist@gmail.com