idnits 2.17.1 draft-ietf-dnsext-dnssec-2535typecode-change-04.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 384 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 9 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: ---------------------------------------------------------------------------- (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 (August 4, 2003) is 7564 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: 'RFC2065' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'RFC3225' is defined on line 345, but no explicit reference was found in the text == Unused Reference: 'RFC2929' is defined on line 348, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-15) exists of draft-ietf-dnsext-delegation-signer-14 ** 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) == Outdated reference: A later version (-06) exists of draft-ietf-dnsext-unknown-rrs-05 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Samuel Weiler 2 Expires: February 2004 August 4, 2003 3 Updates: RFC 2535, [DS] 5 Legacy Resolver Compatibility for Delegation Signer 6 draft-ietf-dnsext-dnssec-2535typecode-change-04.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Comments should be sent to the author or to the DNSEXT WG mailing 31 list: namedroppers@ops.ietf.org 33 Abstract 35 As the DNS Security (DNSSEC) specifications have evolved, the 36 syntax and semantics of the DNSSEC resource records (RRs) have 37 changed. Many deployed nameservers understand variants of these 38 semantics. Dangerous interactions can occur when a resolver that 39 understands an earlier version of these semantics queries an 40 authoritative server that understands the new delegation signer 41 semantics, including at least one failure scenario that will cause 42 an unsecured zone to be unresolvable. This document changes the 43 type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to 44 avoid those interactions. 46 Changes between 03 and 04: 48 Clarified that RRSIG(0) may be defined by standards action. 50 Created a new algorithm registry and renamed the old algorithm 51 registry for SIG(0) only. Added references to the appropriate 52 crypto algorithm and format specifications. 54 Several minor rephrasings. 56 Changes between 02 and 03: 58 KEY (as well as SIG) retained for SIG(0) use only. 60 Changes between 01 and 02: 62 SIG(0) still uses SIG, not RRSIG. Added 2931 reference. 64 Domain names embedded in NSECs and RRSIGs are not compressible and 65 are not downcased. Added unknown-rrs reference (as informative). 67 Simplified the last paragraph of section 3 (NSEC doesn't always 68 signal a negative answer). 70 Changed the suggested type code assignments. 72 Added 2119 reference. 74 Added definitions of "unsecure delegation" and "unsecure referral", 75 since they're not clearly defined elsewhere. 77 Moved 2065 to informative references, not normative. 79 1. Introduction 81 The DNSSEC protocol has been through many iterations whose syntax 82 and semantics are not completely compatible. This has occurred as 83 part of the ordinary process of proposing a protocol, implementing 84 it, testing it in the increasingly complex and diverse environment 85 of the Internet, and refining the definitions of the initial 86 Proposed Standard. In the case of DNSSEC, the process has been 87 complicated by DNS's criticality and wide deployment and the need 88 to add security while minimizing daily operational complexity. 90 A weak area for previous DNS specifications has been lack of detail 91 in specifying resolver behavior, leaving implementors largely on 92 their own to determine many details of resolver function. This, 93 combined with the number of iterations the DNSSEC spec has been 94 through, has resulted in fielded code with a wide variety of 95 behaviors. This variety makes it difficult to predict how a 96 protocol change will be handled by all deployed resolvers. The 97 risk that a change will cause unacceptable or even catastrophic 98 failures makes it difficult to design and deploy a protocol change. 99 One strategy for managing that risk is to structure protocol 100 changes so that existing resolvers can completely ignore input that 101 might confuse them or trigger undesirable failure modes. 103 This document addresses a specific problem caused by Delegation 104 Signer's [DS] introduction of new semantics for the NXT RR that are 105 incompatible with the semantics in RFC 2535 [RFC2535]. Answers 106 provided by DS-aware servers can trigger an unacceptable failure 107 mode in some resolvers that implement RFC 2535, which provides a 108 great disincentive to sign zones with DS. The changes defined in 109 this document allow for the incremental deployment of DS. 111 1.1 Terminology 113 In this document, the term "unsecure delegation" means any 114 delegation for which no DS record appears at the parent. An 115 "unsecure referral" is an answer from the parent containing an NS 116 RRset and a proof that no DS record exists for that name. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 1.2 The Problem 124 Delegation Signer introduces new semantics for the NXT RR that are 125 incompatible with the semantics in RFC 2535. In RFC 2535, NXT 126 records were only required to be returned as part of a 127 non-existence proof. With DS, an unsecure referral returns, in 128 addition to the NS, a proof of non-existence of a DS RR in the form 129 of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was 130 to interpret a response with both an NS and an NXT in the authority 131 section, RCODE=0, and AA=0. Some widely deployed 2535-aware 132 resolvers interpret any answer with an NXT as a proof of 133 non-existence of the requested record. This results in unsecure 134 delegations being invisible to 2535-aware resolvers and violates 135 the basic architectural principle that DNSSEC must do no harm -- 136 the signing of zones must not prevent the resolution of unsecured 137 delegations. 139 2. Possible Solutions 141 This section presents several solutions that were considered. 142 Section 3 describes the one selected. 144 2.1. Change SIG, KEY, and NXT type codes 146 To avoid the problem described above, legacy (RFC2535-aware) 147 resolvers need to be kept from seeing unsecure referrals that 148 include NXT records in the authority section. The simplest way to 149 do that is to change the type codes for SIG, KEY, and NXT. 151 The obvious drawback to this is that new resolvers will not be able 152 to validate zones signed with the old RRs. This problem already 153 exists, however, because of the changes made by DS, and resolvers 154 that understand the old RRs (and have compatibility issues with DS) 155 are far more prevalent than 2535-signed zones. 157 2.2. Change a subset of type codes 159 The observed problem with unsecure referrals could be addressed by 160 changing only the NXT type code or another subset of the type codes 161 that includes NXT. This has the virtue of apparent simplicity, but 162 it risks introducing new problems or not going far enough. It's 163 quite possible that more incompatibilities exist between DS and 164 earlier semantics. Legacy resolvers may also be confused by seeing 165 records they recognize (SIG and KEY) while being unable to find 166 NXTs. Although it may seem unnecessary to fix that which is not 167 obviously broken, it's far cleaner to change all of the type codes 168 at once. This will leave legacy resolvers and tools completely 169 blinded to DNSSEC -- they will see only unknown RRs. 171 2.3. Replace the DO bit 173 Another way to keep legacy resolvers from ever seeing DNSSEC 174 records with DS semantics is to have authoritative servers only 175 send that data to DS-aware resolvers. It's been proposed that 176 assigning a new EDNS0 flag bit to signal DS-awareness (tentatively 177 called "DA"), and having authoritative servers send DNSSEC data 178 only in response to queries with the DA bit set, would accomplish 179 this. This bit would presumably supplant the DO bit described in 180 RFC 3225. 182 This solution is sufficient only if all 2535-aware resolvers zero 183 out EDNS0 flags that they don't understand. If one passed through 184 the DA bit unchanged, it would still see the new semantics, and it 185 would probably fail to see unsecure delegations. Since it's 186 impractical to know how every DNS implementation handles unknown 187 EDNS0 flags, this is not a universal solution. It could, though, 188 be considered in addition to changing the RR type codes. 190 2.4. Increment the EDNS version 192 Another possible solution is to increment the EDNS version number 193 as defined in RFC 2671 [RFC2671], on the assumption that all 194 existing implementations will reject higher versions than they 195 support, and retain the DO bit as the signal for DNSSEC awareness. 196 This approach has not been tested. 198 2.5. Do nothing 200 There is a large deployed base of DNS resolvers that understand 201 DNSSEC as defined by the standards track RFC 2535 and RFC 2065 202 and, due to under specification in those documents, interpret any 203 answer with an NXT as a non-existence proof. So long as that is 204 the case, zone owners will have a strong incentive to not sign any 205 zones that contain unsecure delegations, lest those delegations be 206 invisible to such a large installed base. This will dramatically 207 slow DNSSEC adoption. 209 Unfortunately, without signed zones there's no clear incentive for 210 operators of resolvers to upgrade their software to support the new 211 version of DNSSEC, as defined in [DS]. Historical data suggests 212 that resolvers are rarely upgraded, and that old nameserver code 213 never dies. 215 Rather than wait years for resolvers to be upgraded through natural 216 processes before signing zones with unsecure delegations, 217 addressing this problem with a protocol change will immediately 218 remove the disincentive for signing zones and allow widespread 219 deployment of DNSSEC. 221 3. Protocol changes 223 This document changes the type codes of SIG, KEY, and NXT. This 224 approach is the cleanest and safest of those discussed above, 225 largely because the behavior of resolvers that receive unknown type 226 codes is well understood. This approach has also received the most 227 testing. 229 To avoid operational confusion, it's also necessary to change the 230 mnemonics for these RRs. DNSKEY will be the replacement for KEY, 231 with the mnemonic indicating that these keys are not for 232 application use, per [RFC3445]. RRSIG (Resource Record SIGnature) 233 will replace SIG, and NSEC (Next SECure) will replace NXT. These 234 new types completely replace the old types, except that SIG(0) 235 [RFC2931] will continue to use SIG and KEY. 237 The new types will have exactly the same syntax and semantics as 238 specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for 239 the following: 241 1) Consistent with [UNKNOWN-RRs], domain names embedded in 242 RRSIG and NSEC RRs MUST NOT be compressed, 244 2) Embedded domain names in RRSIG and NSEC RRs are not downcased 245 for purposes of DNSSEC canonical form and ordering nor for 246 equality comparison, and 248 3) An RRSIG with a type-covered field of zero has undefined 249 semantics. The meaning of such a resource record may only be 250 defined by IETF Standards Action. 252 If a resolver receives the old types, it SHOULD treat them as 253 unknown RRs and SHOULD NOT assign any special meaning to them or 254 give them any special treatment. It MUST NOT use them for DNSSEC 255 validations or other DNS operational decision making. For example, 256 a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to 257 validate RRSIGs. If SIG, KEY, or NXT RRs are included in a zone, 258 they MUST NOT receive special treatment. As an example, if a SIG 259 is included in a signed zone, there MUST be an RRSIG for it. 260 Authoritative servers may wish to give error messages when loading 261 zones containing SIG or NXT records (KEY records may be included 262 for SIG(0)). 264 As a clarification to previous documents, some positive responses, 265 particularly wildcard proofs and unsecure referrals, will contain 266 NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as 267 negative answers merely because they contain an NSEC. 269 4. IANA Considerations 271 This document updates the IANA registry for DNS Resource Record 272 Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and 273 DNSKEY RRs, respectively. 275 Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] 276 use only. Type 30 (NXT) should be marked as Obsolete. 278 In order to allow DNS Security and SIG(0) to use different sets of 279 algorithms, the existing "DNS Security Algorithm Numbers" registry 280 is renamed as the "SIG(0) Algorithm Numbers" registry and a new 281 "DNS Security Algorithm Numbers" registry is established. The 282 initial algorithm values are: 284 2 Diffie-Hellman [RFC2539] 285 3 DSA/SHA1 [RFC2536] 286 5 RSA/SHA-1 [RFC3110] 287 253 Private algorithms - domain name [RFC2535] 288 254 Private algorithms - OID [RFC2535] 290 Values 0, 1, and 255 are reserved. Values 4 and 6 through 252 are 291 available for assignment by IETF Standards Action. 293 It is suggested, but not required, that new algorithms usable by 294 both DNS Security and SIG(0) be assigned the same number in both 295 registries. 297 5. Security Considerations 299 The change introduced here does not materially affect security. 300 The implications of trying to use both new and legacy types 301 together are not well understood, and attempts to do so would 302 probably lead to unintended and dangerous results. 304 Changing type codes will leave code paths in legacy resolvers that 305 are never exercised. Unexercised code paths are a frequent source 306 of security holes, largely because those code paths do not get 307 frequent scrutiny. 309 Doing nothing, as described in 3.1, will slow DNSSEC deployment. 310 While this does not decrease security, it also fails to increase 311 it. 313 6. Normative references 315 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 316 RFC 2535, March 1999. 318 [DS] Gudmundsson, O., "Delegation Signer Resource Record", 319 draft-ietf-dnsext-delegation-signer-14.txt, work in 320 progress, May 2003. 322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, March 1997. 325 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures 326 (SIG(0)s)", RFC 2931, September 2000. 328 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name 329 System (DNS)", RFC 2436, March 1999. 331 [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the 332 Domain Name System (DNS)", RFC 2539, March 1999. 334 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the 335 Domain Name System (DNS)", RFC 3110, May 2001. 337 7. Informative References 339 [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security 340 Extensions", RFC 2065, January 1997. 342 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 343 2671, August 1999. 345 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 346 3225, December 2001. 348 [RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning. 349 Domain Name System (DNS) IANA Considerations. BCP 42, 350 RFC 2929, September 2000. 352 [RFC3445] Massey, D., and S. Rose. Limiting the Scope of the KEY 353 Resource Record (RR). RFC 3445, December 2002. 355 [UNKNOWN-RRs] Gustafsson, A. Handling of Unknown DNS Resource 356 Record Types. draft-ietf-dnsext-unknown-rrs-05.txt 357 Publication as RFC pending. 359 8. Acknowledgments 361 The changes introduced here and the analysis of alternatives had 362 many contributors. With apologies to anyone overlooked, those 363 include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed 364 Lewis, Bill Manning, and Suzanne Woolf. 366 Thanks to Jakob Schlyter and Mark Andrews for identifying the 367 incompatibility described in section 1.2. 369 In addition to the above, the author would like to thank Scott 370 Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive 371 comments. 373 9. Author's Address 375 Samuel Weiler 376 SPARTA, Inc. 377 7075 Samuel Morse Drive 378 Columbia, MD 21046 379 USA 380 weiler@tislabs.com