idnits 2.17.1 draft-ietf-dnsext-dnssec-2535typecode-change-03.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 346 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 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 (June 29, 2003) is 7607 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 299, but no explicit reference was found in the text == Unused Reference: 'RFC3225' is defined on line 305, but no explicit reference was found in the text == Unused Reference: 'RFC2929' is defined on line 308, 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 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: 3 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: December 2003 June 29, 2003 3 Updates: RFC 2535, [DS] 5 Legacy Resolver Compatibility for Delegation Signer 6 draft-ietf-dnsext-dnssec-2535typecode-change-03.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 proposes that 43 these interactions be avoided by changing the type codes and 44 mnemonics of the DNSSEC RRs (SIG, KEY, and NXT). 46 Changes between 02 and 03: 48 KEY (as well as SIG) retained for SIG(0) use only. 50 Changes between 01 and 02: 52 SIG(0) still uses SIG, not RRSIG. Added 2931 reference. 54 Domain names embedded in NSECs and RRSIGs are not compressible and 55 are not downcased. Added unknown-rrs reference (as informative). 57 Simplified the last paragraph of section 3 (NSEC doesn't always 58 signal a negative answer). 60 Changed the suggested type code assignments. 62 Added 2119 reference. 64 Added definitions of "unsecure delegation" and "unsecure referral", 65 since they're not clearly defined elsewhere. 67 Moved 2065 to informative references, not normative. 69 1. Introduction 71 The DNSSEC protocol has been through many iterations whose syntax 72 and semantics are not completely compatible. This has occurred as 73 part of the ordinary process of proposing a protocol, implementing 74 it, testing it in the increasingly complex and diverse environment 75 of the Internet, and refining the definitions of the initial 76 Proposed Standard. In the case of DNSSEC, the process has been 77 complicated by DNS's criticality and wide deployment and the need 78 to add security while minimizing daily operational complexity. 80 A weak area for previous DNS specifications has been lack of detail 81 in specifying resolver behavior, leaving implementors largely on 82 their own to determine many details of resolver function. This, 83 combined with the number of iterations the DNSSEC spec has been 84 through, has resulted in fielded code with a wide variety of 85 behaviors. This variety makes it difficult to predict how a 86 protocol change will be handled by all deployed resolvers. The 87 risk that a change will cause unacceptable or even catastrophic 88 failures makes it difficult to design and deploy a protocol change. 89 One strategy for managing that risk is to structure protocol 90 changes so that existing resolvers can completely ignore input that 91 might confuse them or trigger undesirable failure modes. 93 This document addresses a specific problem caused by Delegation 94 Signer's [DS] introduction of new semantics for the NXT RR that are 95 incompatible with the semantics in RFC 2535 [RFC2535]. Answers 96 provided by DS-aware servers can trigger an unacceptable failure 97 mode in some resolvers that implement RFC 2535, which provides a 98 great disincentive to sign zones with DS. The proposed solution 99 allows for the incremental deployment of DS. 101 1.1 Terminology 103 In this document, the term "unsecure delegation" means any 104 delegation for which no DS record appears at the parent. An 105 "unsecure referral" is an answer from the parent containing an NS 106 RRset and a proof that no DS record exists for that name. 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 1.2 The Problem 114 Delegation Signer introduces new semantics for the NXT RR that are 115 incompatible with the semantics in RFC 2535. In RFC 2535, NXT 116 records were only required to be returned as part of a 117 non-existence proof. With DS, an unsecure referral returns, in 118 addition to the NS, a proof of non-existence of a DS RR in the form 119 of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was 120 to interpret a response with both an NS and an NXT in the authority 121 section, RCODE=0, and AA=0. Some widely deployed 2535-aware 122 resolvers interpret any answer with an NXT as a proof of 123 non-existence of the requested record. This results in unsecure 124 delegations being invisible to 2535-aware resolvers and violates 125 the basic architectural principle that DNSSEC must do no harm -- 126 the signing of zones must not prevent the resolution of unsecured 127 delegations. 129 2. Possible Solutions 131 This section presents several possible solutions. Section 3 132 recommends one and describes it in more detail. 134 2.1. Change SIG, KEY, and NXT type codes 136 To avoid the problem described above, legacy (RFC2535-aware) 137 resolvers need to be kept from seeing unsecure referrals that 138 include NXT records in the authority section. The simplest way to 139 do that is to change the type codes for SIG, KEY, and NXT. 141 The obvious drawback to this is that new resolvers will not be able 142 to validate zones signed with the old RRs. This problem already 143 exists, however, because of the changes made by DS, and resolvers 144 that understand the old RRs (and have compatibility issues with DS) 145 are far more prevalent than 2535-signed zones. 147 2.2. Change a subset of type codes 149 The observed problem with unsecure referrals could be addressed by 150 changing only the NXT type code or another subset of the type codes 151 that includes NXT. This has the virtue of apparent simplicity, but 152 it risks introducing new problems or not going far enough. It's 153 quite possible that more incompatibilities exist between DS and 154 earlier semantics. Legacy resolvers may also be confused by seeing 155 records they recognize (SIG and KEY) while being unable to find 156 NXTs. Although it may seem unnecessary to fix that which is not 157 obviously broken, it's far cleaner to change all of the type codes 158 at once. This will leave legacy resolvers and tools completely 159 blinded to DNSSEC -- they will see only unknown RRs. 161 2.3. Replace the DO bit 163 Another way to keep legacy resolvers from ever seeing DNSSEC 164 records with DS semantics is to have authoritative servers only 165 send that data to DS-aware resolvers. It's been proposed that 166 assigning a new EDNS0 flag bit to signal DS-awareness (tentatively 167 called "DA"), and having authoritative servers send DNSSEC data 168 only in response to queries with the DA bit set, would accomplish 169 this. This bit would presumably supplant the DO bit described in 170 RFC 3225. 172 This solution is sufficient only if all 2535-aware resolvers zero 173 out EDNS0 flags that they don't understand. If one passed through 174 the DA bit unchanged, it would still see the new semantics, and it 175 would probably fail to see unsecure delegations. Since it's 176 impractical to know how every DNS implementation handles unknown 177 EDNS0 flags, this is not a universal solution. It could, though, 178 be considered in addition to changing the RR type codes. 180 2.4. Increment the EDNS version 182 Another proposed solution is to increment the EDNS version number 183 as defined in RFC 2671 [RFC2671], on the assumption that all 184 existing implementations will reject higher versions than they 185 support, and retain the DO bit as the signal for DNSSEC awareness. 186 This approach has not been tested. 188 2.5. Do nothing 190 There is a large deployed base of DNS resolvers that understand 191 DNSSEC as defined by the standards track RFC 2535 and RFC 2065 192 and, due to under specification in those documents, interpret any 193 answer with an NXT as a non-existence proof. So long as that is 194 the case, zone owners will have a strong incentive to not sign any 195 zones that contain unsecure delegations, lest those delegations be 196 invisible to such a large installed base. This will dramatically 197 slow DNSSEC adoption. 199 Unfortunately, without signed zones there's no clear incentive for 200 operators of resolvers to upgrade their software to support the new 201 version of DNSSEC, as defined in [DS]. Historical data suggests 202 that resolvers are rarely upgraded, and that old nameserver code 203 never dies. 205 Rather than wait years for resolvers to be upgraded through natural 206 processes before signing zones with unsecure delegations, 207 addressing this problem with a protocol change will immediately 208 remove the disincentive for signing zones and allow widespread 209 deployment of DNSSEC. 211 3. Protocol changes 213 This document proposes changing the type codes of SIG, KEY, and 214 NXT. This approach is the cleanest and safest of those discussed 215 above, largely because the behavior of resolvers that receive 216 unknown type codes is well understood. This approach has also 217 received the most testing. 219 To avoid operational confusion, it's also necessary to change the 220 mnemonics for these RRs. DNSKEY will be the replacement for KEY, 221 with the mnemonic indicating that these keys are not for 222 application use, per [RFC3445]. RRSIG (Resource Record SIGnature) 223 will replace SIG, and NSEC (Next SECure) will replace NXT. These 224 new types completely replace the old types, except that SIG(0) 225 [RFC2931] will continue to use SIG and KEY. 227 The new types will have exactly the same syntax and semantics as 228 specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for 229 the following: 231 1) Consistent with [UNKNOWN-RRs], domain names embedded in 232 RRSIG and NSEC RRs MUST NOT be compressed, 234 2) Embedded domain names in RRSIG and NSEC RRs are not downcased 235 for purposes of DNSSEC canonical form and ordering nor for 236 equality comparison, and 238 3) An RRSIG with a type covered field of zero has undefined 239 semantics. 241 If a resolver receives the old types, it SHOULD treat them as 242 unknown RRs and SHOULD NOT assign any special semantic value to 243 them. It MUST NOT use them for DNSSEC validations or other DNS 244 operational decision making. For example, a resolver MUST NOT use 245 DNSKEYs to validate SIGs or use KEYs to validate RRSIGs. If SIG, 246 KEY, or NXT RRs are included in a zone, they MUST NOT receive 247 special treatment. As an example, if a SIG is included in a signed 248 zone, there MUST be an RRSIG for it. Authoritative servers may 249 wish to give error messages when loading zones containing SIG or 250 NXT records (KEY records may be included for SIG(0)). 252 As a clarification to previous documents, some positive responses, 253 particularly wildcard proofs and unsecure referrals, will contain 254 NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as 255 negative answers merely because they contain an NSEC. 257 4. IANA Considerations 259 This document updates the IANA registry for DNS Resource Record 260 Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and 261 DNSKEY RRs, respectively. 263 Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] 264 use only. Type 30 (NXT) should be marked as Obsolete. 266 5. Security Considerations 268 The change proposed here does not materially affect security. The 269 implications of trying to use both new and legacy types together 270 are not well understood, and attempts to do so would probably lead 271 to unintended and dangerous results. 273 Changing type codes will leave code paths in legacy resolvers that 274 are never exercised. Unexercised code paths are a frequent source 275 of security holes, largely because those code paths do not get 276 frequent scrutiny. 278 Doing nothing, as described in 3.1, will slow DNSSEC deployment. 279 While this does not decrease security, it also fails to increase 280 it. 282 6. Normative references 284 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 285 RFC 2535, March 1999. 287 [DS] Gudmundsson, O., "Delegation Signer Resource Record", 288 draft-ietf-dnsext-delegation-signer-14.txt, work in 289 progress, May 2003. 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, March 1997. 294 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures 295 (SIG(0)s)", RFC 2931, September 2000. 297 7. Informative References 299 [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security 300 Extensions", RFC 2065, January 1997. 302 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 303 2671, August 1999. 305 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 306 3225, December 2001. 308 [RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning. 309 Domain Name System (DNS) IANA Considerations. BCP 42, 310 RFC 2929, September 2000. 312 [RFC3445] Massey, D., and S. Rose. Limiting the Scope of the KEY 313 Resource Record (RR). RFC 3445, December 2002. 315 [UNKNOWN-RRs] Gustafsson, A. Handling of Unknown DNS Resource 316 Record Types. draft-ietf-dnsext-unknown-rrs-05.txt 317 Publication as RFC pending. 319 8. Acknowledgments 321 The proposed solution and the analysis of alternatives had many 322 contributors. With apologies to anyone overlooked, those include: 323 Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed Lewis, 324 Bill Manning, and Suzanne Woolf. 326 Thanks to Jakob Schlyter and Mark Andrews for identifying the 327 incompatibility described in section 1.2. 329 In addition to the above, the author would like to thank Scott 330 Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive 331 comments. 333 9. Author's Address 335 Samuel Weiler 336 SPARTA, Inc. 337 7075 Samuel Morse Drive 338 Columbia, MD 21046 339 USA 340 weiler@tislabs.com