idnits 2.17.1 draft-ietf-dnsext-dnssec-2535typecode-change-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 442 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of lines with control characters in the document. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2535, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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. (Using the creation date from RFC2535, updated by this document, for RFC5378 checks: 1997-07-24) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 15, 2003) is 7435 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) == Unused Reference: 'RFC2536' is defined on line 389, but no explicit reference was found in the text == Unused Reference: 'RFC2539' is defined on line 392, but no explicit reference was found in the text == Unused Reference: 'RFC3110' is defined on line 395, but no explicit reference was found in the text == Unused Reference: 'RFC2065' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'RFC3225' is defined on line 406, but no explicit reference was found in the text == Unused Reference: 'RFC2929' is defined on line 409, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2436 (ref. 'RFC2536') (Obsoleted by RFC 3356) -- Obsolete informational reference (is this intentional?): RFC 2065 (Obsoleted by RFC 2535) -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 2929 (Obsoleted by RFC 5395) -- Obsolete informational reference (is this intentional?): RFC 3445 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Samuel Weiler 3 Expires: June 2004 December 15, 2003 4 Updates: RFC 2535, [DS] 6 Legacy Resolver Compatibility for Delegation Signer 7 draft-ietf-dnsext-dnssec-2535typecode-change-06.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Comments should be sent to the author or to the DNSEXT WG mailing 32 list: namedroppers@ops.ietf.org 34 Abstract 36 As the DNS Security (DNSSEC) specifications have evolved, the 37 syntax and semantics of the DNSSEC resource records (RRs) have 38 changed. Many deployed nameservers understand variants of these 39 semantics. Dangerous interactions can occur when a resolver that 40 understands an earlier version of these semantics queries an 41 authoritative server that understands the new delegation signer 42 semantics, including at least one failure scenario that will cause 43 an unsecured zone to be unresolvable. This document changes the 44 type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to 45 avoid those interactions. 47 Changes between 05 and 06: 49 Signifigantly reworked the IANA section -- went back to one 50 algorithm registry. 52 Removed Diffie-Hellman from the list of zone-signing algorithms 53 (leaving only DSA, RSA/SHA-1, and private algorithms). 55 Added a DNSKEY flags field registry. 57 Changes between 04 and 05: 59 IESG approved publication. 61 Cleaned up an internal reference in the acknowledgements section. 63 Retained KEY and SIG for TKEY, too. Added TKEY (2930) reference. 65 Changed the names of both new registries. Added algorithm 66 mnemonics to the new zone signing algorithm registry. Minor 67 rewording in the IANA section for clarity. 69 Cleaned up formatting of references. Replaced unknown-rr draft 70 references with RFC3597. Bumped DS version number. 72 Changes between 03 and 04: 74 Clarified that RRSIG(0) may be defined by standards action. 76 Created a new algorithm registry and renamed the old algorithm 77 registry for SIG(0) only. Added references to the appropriate 78 crypto algorithm and format specifications. 80 Several minor rephrasings. 82 Changes between 02 and 03: 84 KEY (as well as SIG) retained for SIG(0) use only. 86 Changes between 01 and 02: 88 SIG(0) still uses SIG, not RRSIG. Added 2931 reference. 90 Domain names embedded in NSECs and RRSIGs are not compressible and 91 are not downcased. Added unknown-rrs reference (as informative). 93 Simplified the last paragraph of section 3 (NSEC doesn't always 94 signal a negative answer). 96 Changed the suggested type code assignments. 98 Added 2119 reference. 100 Added definitions of "unsecure delegation" and "unsecure referral", 101 since they're not clearly defined elsewhere. 103 Moved 2065 to informative references, not normative. 105 1. Introduction 107 The DNSSEC protocol has been through many iterations whose syntax 108 and semantics are not completely compatible. This has occurred as 109 part of the ordinary process of proposing a protocol, implementing 110 it, testing it in the increasingly complex and diverse environment 111 of the Internet, and refining the definitions of the initial 112 Proposed Standard. In the case of DNSSEC, the process has been 113 complicated by DNS's criticality and wide deployment and the need 114 to add security while minimizing daily operational complexity. 116 A weak area for previous DNS specifications has been lack of detail 117 in specifying resolver behavior, leaving implementors largely on 118 their own to determine many details of resolver function. This, 119 combined with the number of iterations the DNSSEC spec has been 120 through, has resulted in fielded code with a wide variety of 121 behaviors. This variety makes it difficult to predict how a 122 protocol change will be handled by all deployed resolvers. The 123 risk that a change will cause unacceptable or even catastrophic 124 failures makes it difficult to design and deploy a protocol change. 125 One strategy for managing that risk is to structure protocol 126 changes so that existing resolvers can completely ignore input that 127 might confuse them or trigger undesirable failure modes. 129 This document addresses a specific problem caused by Delegation 130 Signer's [DS] introduction of new semantics for the NXT RR that are 131 incompatible with the semantics in RFC 2535 [RFC2535]. Answers 132 provided by DS-aware servers can trigger an unacceptable failure 133 mode in some resolvers that implement RFC 2535, which provides a 134 great disincentive to sign zones with DS. The changes defined in 135 this document allow for the incremental deployment of DS. 137 1.1 Terminology 139 In this document, the term "unsecure delegation" means any 140 delegation for which no DS record appears at the parent. An 141 "unsecure referral" is an answer from the parent containing an NS 142 RRset and a proof that no DS record exists for that name. 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 1.2 The Problem 150 Delegation Signer introduces new semantics for the NXT RR that are 151 incompatible with the semantics in RFC 2535. In RFC 2535, NXT 152 records were only required to be returned as part of a 153 non-existence proof. With DS, an unsecure referral returns, in 154 addition to the NS, a proof of non-existence of a DS RR in the form 155 of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was 156 to interpret a response with both an NS and an NXT in the authority 157 section, RCODE=0, and AA=0. Some widely deployed 2535-aware 158 resolvers interpret any answer with an NXT as a proof of 159 non-existence of the requested record. This results in unsecure 160 delegations being invisible to 2535-aware resolvers and violates 161 the basic architectural principle that DNSSEC must do no harm -- 162 the signing of zones must not prevent the resolution of unsecured 163 delegations. 165 2. Possible Solutions 167 This section presents several solutions that were considered. 168 Section 3 describes the one selected. 170 2.1. Change SIG, KEY, and NXT type codes 172 To avoid the problem described above, legacy (RFC2535-aware) 173 resolvers need to be kept from seeing unsecure referrals that 174 include NXT records in the authority section. The simplest way to 175 do that is to change the type codes for SIG, KEY, and NXT. 177 The obvious drawback to this is that new resolvers will not be able 178 to validate zones signed with the old RRs. This problem already 179 exists, however, because of the changes made by DS, and resolvers 180 that understand the old RRs (and have compatibility issues with DS) 181 are far more prevalent than 2535-signed zones. 183 2.2. Change a subset of type codes 185 The observed problem with unsecure referrals could be addressed by 186 changing only the NXT type code or another subset of the type codes 187 that includes NXT. This has the virtue of apparent simplicity, but 188 it risks introducing new problems or not going far enough. It's 189 quite possible that more incompatibilities exist between DS and 190 earlier semantics. Legacy resolvers may also be confused by seeing 191 records they recognize (SIG and KEY) while being unable to find 192 NXTs. Although it may seem unnecessary to fix that which is not 193 obviously broken, it's far cleaner to change all of the type codes 194 at once. This will leave legacy resolvers and tools completely 195 blinded to DNSSEC -- they will see only unknown RRs. 197 2.3. Replace the DO bit 199 Another way to keep legacy resolvers from ever seeing DNSSEC 200 records with DS semantics is to have authoritative servers only 201 send that data to DS-aware resolvers. It's been proposed that 202 assigning a new EDNS0 flag bit to signal DS-awareness (tentatively 203 called "DA"), and having authoritative servers send DNSSEC data 204 only in response to queries with the DA bit set, would accomplish 205 this. This bit would presumably supplant the DO bit described in 206 RFC 3225. 208 This solution is sufficient only if all 2535-aware resolvers zero 209 out EDNS0 flags that they don't understand. If one passed through 210 the DA bit unchanged, it would still see the new semantics, and it 211 would probably fail to see unsecure delegations. Since it's 212 impractical to know how every DNS implementation handles unknown 213 EDNS0 flags, this is not a universal solution. It could, though, 214 be considered in addition to changing the RR type codes. 216 2.4. Increment the EDNS version 218 Another possible solution is to increment the EDNS version number 219 as defined in RFC 2671 [RFC2671], on the assumption that all 220 existing implementations will reject higher versions than they 221 support, and retain the DO bit as the signal for DNSSEC awareness. 222 This approach has not been tested. 224 2.5. Do nothing 226 There is a large deployed base of DNS resolvers that understand 227 DNSSEC as defined by the standards track RFC 2535 and RFC 2065 228 and, due to under specification in those documents, interpret any 229 answer with an NXT as a non-existence proof. So long as that is 230 the case, zone owners will have a strong incentive to not sign any 231 zones that contain unsecure delegations, lest those delegations be 232 invisible to such a large installed base. This will dramatically 233 slow DNSSEC adoption. 235 Unfortunately, without signed zones there's no clear incentive for 236 operators of resolvers to upgrade their software to support the new 237 version of DNSSEC, as defined in [DS]. Historical data suggests 238 that resolvers are rarely upgraded, and that old nameserver code 239 never dies. 241 Rather than wait years for resolvers to be upgraded through natural 242 processes before signing zones with unsecure delegations, 243 addressing this problem with a protocol change will immediately 244 remove the disincentive for signing zones and allow widespread 245 deployment of DNSSEC. 247 3. Protocol changes 249 This document changes the type codes of SIG, KEY, and NXT. This 250 approach is the cleanest and safest of those discussed above, 251 largely because the behavior of resolvers that receive unknown type 252 codes is well understood. This approach has also received the most 253 testing. 255 To avoid operational confusion, it's also necessary to change the 256 mnemonics for these RRs. DNSKEY will be the replacement for KEY, 257 with the mnemonic indicating that these keys are not for 258 application use, per [RFC3445]. RRSIG (Resource Record SIGnature) 259 will replace SIG, and NSEC (Next SECure) will replace NXT. These 260 new types completely replace the old types, except that SIG(0) 261 [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY. 263 The new types will have exactly the same syntax and semantics as 264 specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for 265 the following: 267 1) Consistent with [RFC3597], domain names embedded in 268 RRSIG and NSEC RRs MUST NOT be compressed, 270 2) Embedded domain names in RRSIG and NSEC RRs are not downcased 271 for purposes of DNSSEC canonical form and ordering nor for 272 equality comparison, and 274 3) An RRSIG with a type-covered field of zero has undefined 275 semantics. The meaning of such a resource record may only be 276 defined by IETF Standards Action. 278 If a resolver receives the old types, it SHOULD treat them as 279 unknown RRs and SHOULD NOT assign any special meaning to them or 280 give them any special treatment. It MUST NOT use them for DNSSEC 281 validations or other DNS operational decision making. For example, 282 a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to 283 validate RRSIGs. If SIG, KEY, or NXT RRs are included in a zone, 284 they MUST NOT receive special treatment. As an example, if a SIG 285 is included in a signed zone, there MUST be an RRSIG for it. 286 Authoritative servers may wish to give error messages when loading 287 zones containing SIG or NXT records (KEY records may be included 288 for SIG(0) or TKEY). 290 As a clarification to previous documents, some positive responses, 291 particularly wildcard proofs and unsecure referrals, will contain 292 NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as 293 negative answers merely because they contain an NSEC. 295 4. IANA Considerations 297 4.1 DNS Resource Record Types 299 This document updates the IANA registry for DNS Resource Record 300 Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and 301 DNSKEY RRs, respectively. 303 Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and 304 TKEY [RFC2930] use only. 306 Type 30 (NXT) should be marked as Obsolete. 308 4.2 DNS Security Algorithm Numbers 310 To allow zone signing (DNSSEC) and transaction security mechanisms 311 (SIG(0) and TKEY) to use different sets of algorithms, the existing 312 "DNS Security Algorithm Numbers" registry is modified to include 313 the applicability of each algorithm. Specifically, two new columns 314 are added to the registry, showing whether each algorithm may be 315 used for zone signing, transaction security mechanisms, or both. 316 Only algorithms usable for zone signing may be used in DNSKEY, 317 RRSIG, and DS RRs. Only algorithms usable for SIG(0) and/or TSIG 318 may be used in SIG and KEY RRs. 320 All currently defined algorithms remain usable for transaction 321 security mechanisms. Only RSA/SHA-1, DSA/SHA-1, and private 322 algorithms (types 253 and 254) may be used for zone signing. Note 323 that the registry does not contain the requirement level of each 324 algorithm, only whether or not an algorithm may be used for the 325 given purposes. For example, RSA/MD5, while allowed for 326 transaction security mechanisms, is NOT RECOMMENDED, per RFC3110. 328 Additionally, the presentation format algorithm mnemonics from 329 RFC2535 Section 7 are added to the registry. This document assigns 330 RSA/SHA-1 the mnemonic RSASHA1. 332 As before, assignment of new algorithms in this registry requires 333 IETF Standards Action. Additionally, modification of algorithm 334 mnemonics or applicability requires IETF Standards Action. 335 Documents defining a new algorithm must address the applicability 336 of the algorithm and should assign a presentation mnemonic to the 337 algorithm. 339 4.3 DNSKEY Flags 341 Like the KEY resource record, DNSKEY contains a 16-bit flags field. 342 This document creates a new registry for the DNSKEY flags field. 344 Initially, this registry only contains an assignment for bit 7 (the 345 ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF 346 Standards Action. 348 4.4 DNSKEY Protocol Octet 350 Like the KEY resource record, DNSKEY contains an eight bit protocol 351 field. The only defined value for this field is 3 (DNSSEC). No 352 other values are allowed, hence no IANA registry is needed for this 353 field. 355 5. Security Considerations 357 The changes introduced here do not materially affect security. 358 The implications of trying to use both new and legacy types 359 together are not well understood, and attempts to do so would 360 probably lead to unintended and dangerous results. 362 Changing type codes will leave code paths in legacy resolvers that 363 are never exercised. Unexercised code paths are a frequent source 364 of security holes, largely because those code paths do not get 365 frequent scrutiny. 367 Doing nothing, as described in section 2.5, will slow DNSSEC 368 deployment. While this does not decrease security, it also fails 369 to increase it. 371 6. Normative references 373 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 374 RFC 2535, March 1999. 376 [DS] Gudmundsson, O., "Delegation Signer Resource Record", 377 draft-ietf-dnsext-delegation-signer-15.txt, work in 378 progress, June 2003. 380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 381 Requirement Levels", BCP 14, RFC 2119, March 1997. 383 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures 384 (SIG(0)s)", RFC 2931, September 2000. 386 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY 387 RR)", RFC 2930, September 2000. 389 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name 390 System (DNS)", RFC 2436, March 1999. 392 [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the 393 Domain Name System (DNS)", RFC 2539, March 1999. 395 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the 396 Domain Name System (DNS)", RFC 3110, May 2001. 398 7. Informative References 400 [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security 401 Extensions", RFC 2065, January 1997. 403 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 404 2671, August 1999. 406 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 407 3225, December 2001. 409 [RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning, 410 "Domain Name System (DNS) IANA Considerations", BCP 42, 411 RFC 2929, September 2000. 413 [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY 414 Resource Record (RR)", RFC 3445, December 2002. 416 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource 417 Record (RR) Types", RFC 3597, September 2003. 419 8. Acknowledgments 421 The changes introduced here and the analysis of alternatives had 422 many contributors. With apologies to anyone overlooked, those 423 include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed 424 Lewis, Bill Manning, and Suzanne Woolf. 426 Thanks to Jakob Schlyter and Mark Andrews for identifying the 427 incompatibility described in section 1.2. 429 In addition to the above, the author would like to thank Scott 430 Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive 431 comments. 433 9. Author's Address 435 Samuel Weiler 436 SPARTA, Inc. 437 7075 Samuel Morse Drive 438 Columbia, MD 21046 439 USA 440 weiler@tislabs.com