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