idnits 2.17.1 draft-ietf-dnsext-dnssec-2535typecode-change-01.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 287 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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 192: '... old types, SHOULD treat them as unk...' RFC 2119 keyword, line 193: '...lue to them. It MUST NOT use them for...' RFC 2119 keyword, line 195: '...mple, a resolver MUST NOT use DNSKEYs ...' RFC 2119 keyword, line 196: '...Authoritative servers SHOULD NOT serve...' RFC 2119 keyword, line 197: '... those records are included, they MUST...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (May 22, 2003) is 7617 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 255, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) ** 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 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: 6 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Samuel Weiler 2 Expires: November 2003 May 22, 2003 4 Legacy Resolver Compatibility for Delegation Signer 5 draft-ietf-dnsext-dnssec-2535typecode-change-01.txt 7 Status of this Memo 9 This document is an Internet-Draft and is subject to all provisions 10 of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- Drafts 20 as reference material or to cite them other than as "work in 21 progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Comments should be sent to the author or to the DNSEXT WG mailing 30 list: namedroppers@ops.ietf.org 32 Abstract 34 As the DNS Security (DNSSEC) specifications have evolved, the 35 syntax and semantics of the DNSSEC resource records (RRs) have 36 changed. Many deployed nameservers understand variants of these 37 semantics. Dangerous interactions can occur when a resolver that 38 understands an earlier version of these semantics queries an 39 authoritative server that understands the new delegation signer 40 semantics, including at least one failure scenario that will cause 41 an unsecured zone to be unresolvable. This document proposes that 42 these interactions be avoided by changing the type codes and 43 mnemonics of the DNSSEC RRs (SIG, KEY, and NXT). 45 1. Introduction 47 The DNSSEC protocol has been through many iterations whose syntax 48 and semantics are not completely compatible. This has occurred as 49 part of the ordinary process of proposing a protocol, implementing 50 it, testing it in the increasingly complex and diverse environment 51 of the Internet, and refining the definitions of the initial 52 Proposed Standard. In the case of DNSSEC, the process has been 53 complicated by DNS's criticality and wide deployment and the need 54 to add security while minimizing daily operational complexity. 56 A weak area for previous DNS specifications has been lack of detail 57 in specifying resolver behavior, leaving implementors largely on 58 their own to determine many details of resolver function. This, 59 combined with the number of iterations the DNSSEC spec has been 60 through, has resulted in fielded code with a wide variety of 61 behaviors. This variety makes it difficult to predict how a 62 protocol change will be handled by all deployed resolvers. The 63 risk that a change will cause unacceptable or even catastrophic 64 failures makes it difficult to design and deploy a protocol change. 65 One strategy for managing that risk is to structure protocol 66 changes so that existing resolvers can completely ignore input that 67 might confuse them or trigger undesirable failure modes. 69 This document addresses a specific problem caused by Delegation 70 Signer's [DS] introduction of new semantics for the NXT RR that are 71 incompatible with the semantics in [RFC2535]. Answers provided by 72 DS-aware servers can trigger an unacceptable failure mode in some 73 resolvers that implement RFC 2535, which provides a great 74 disincentive to sign zones with DS. The proposed solution allows 75 for the incremental deployment of DS. 77 1.1 The Problem 79 Delegation signer [DS] introduces new semantics for the NXT RR that 80 are incompatible with the semantics in [RFC2535]. In [RFC2535], 81 NXT records were only required to be returned as part of a 82 non-existence proof. In [DS], an unsecure referral returns, in 83 addition to the NS, a proof of non-existence of a DS RR in the form 84 of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was 85 to interpret a response with both an NS and an NXT in the authority 86 section and with NOERROR or NODATA set. Some widely deployed 87 2535-aware resolvers interpret any answer with an NXT as a proof of 88 non-existence of the requested record. This results in unsecure 89 delegations being invisible to 2535-aware resolvers and violates 90 the basic architectural principle that DNSSEC must do no harm -- 91 the signing of zones must not prevent the resolution of unsecured 92 names. 94 2. Possible Solutions 96 This section presents several possible solutions. Section 3 97 recommends one and describes it in more detail. 99 2.1. Change SIG, KEY, and NXT 101 To avoid the problem described above, legacy (RFC2535-aware) 102 resolvers need to be kept from seeing unsecure referrals that 103 include NXT records in the authority section. The simplest way to 104 do that is to change the type codes for SIG, KEY, and NXT. 106 The obvious drawback to this is that new resolvers will not be able 107 to validate zones signed with the old RRs. This problem already 108 exists, however, because of the changes made by DS, and resolvers 109 that understand the old RRs (and have compatibility issues with DS) 110 are far more prevalent than 2535-signed zones. 112 2.2. Change a subset of type codes 114 The observed problem with unsecure referrals could be addressed by 115 changing only the NXT type code or another subset of the type codes 116 that includes NXT. This has the virtue of apparent simplicity, but 117 it risks introducing new problems or not going far enough. It's 118 quite possible that more incompatibilities exist between DS and 119 earlier semantics. Legacy resolvers may also be confused by seeing 120 records they recognize (SIG and KEY) while being unable to find 121 NXTs. Although it may seem unnecessary to fix that which is not 122 obviously broken, it's far cleaner to change all of the type codes 123 at once. This will leave legacy resolvers and tools completely 124 blinded to DNSSEC -- they will see only unknown RRs. 126 2.3. Replace the DO bit 128 Another way to keep legacy resolvers from ever seeing DNSSEC 129 records with DS semantics is to have authoritative servers only 130 send that data to DS-aware resolvers. It's been proposed that 131 assigning a new EDNS0 flag bit to signal DS-awareness (tentatively 132 called "DA"), and having authoritative servers send DNSSEC data 133 only in response to queries with the DA bit set, would accomplish 134 this. This bit would presumably supplant the DO bit described in 135 [RFC3225]. 137 This solution is sufficient only if all 2535-aware resolvers zero 138 out EDNS0 flags that they don't understand. If one passed through 139 the DA bit unchanged, it would still see the new semantics, and it 140 would probably fail to see unsecure delegations. Since it's 141 impractical to know how every DNS implementation handles unknown 142 EDNS0 flags, this is not a universal solution. It could, though, 143 be considered in addition to changing the RR type codes. 145 2.4. Increment the EDNS version 147 Another proposed solution is to increment the EDNS version number 148 as defined in [RFC2671], on the assumption that all existing 149 implementations will reject higher versions than they support, 150 and retain the DO bit as the signal for DNSSEC awareness. This 151 approach has not been tested. 153 2.5. Do nothing 155 There is a large deployed base of DNS resolvers that understand 156 DNSSEC as defined by the standards track [RFC2535] and [RFC2065] 157 and, due to underspecification in those documents, interpret any 158 answer with an NXT as a non-existence proof. So long as that is 159 the case, zone owners will have a strong incentive to not sign any 160 zones that contain unsecure delegations, lest those delegations be 161 invisible to such a large installed base. This will dramatically 162 slow DNSSEC adoption. 164 Unfortunately, without signed zones there's no clear incentive for 165 operators of resolvers to upgrade their software to support the new 166 version of DNSSEC, as defined in [DS]. Historical data suggests 167 that resolvers are rarely upgraded, and that old nameserver code 168 never dies. 170 Rather than wait years for resolvers to be upgraded through natural 171 processes before signing zones with unsecure delegations, 172 addressing this problem with a protocol change will immediately 173 remove the disincentive for signing zones and allow widespread 174 deployment of DNSSEC. 176 3. Protocol changes 178 This document proposes changing the type codes of SIG, KEY, and 179 NXT. This solution is the cleanest and safest, largely because the 180 behavior of resolvers that receive unknown type codes is well 181 understood. This approach has also received the most testing. 183 To avoid operational confusion, it's also necessary to change the 184 mnemonics for these RRs. DNSKEY will be the replacement for KEY, 185 with the mnemonic indicating that these keys are not for 186 application use, per [RFC3445]. RRSIG (Resource Record SIGnature) 187 will replace SIG, and NSEC (Next SECure) will replace NXT. 189 The new types will have exactly the same syntax and semantics as 190 specified for SIG, KEY, and NXT in [RFC2535] and [DS], and they 191 completely replace the old types. A resolver, if it receives the 192 old types, SHOULD treat them as unknown RRs, and SHOULD NOT assign 193 any special semantic value to them. It MUST NOT use them for 194 DNSSEC validations or other DNS operational decision making. For 195 example, a resolver MUST NOT use DNSKEYs to validate SIGs or use 196 KEYs to validate RRSIGs. Authoritative servers SHOULD NOT serve 197 SIG, KEY, or NXT records. If those records are included, they MUST 198 NOT receive special treatment. As an example, if a SIG is included 199 in a signed zone, there MUST be an RRSIG for it. 201 As a clarification to previous documents, many positive responses, 202 including wildcard proofs and insecure referrals, will contain NSEC 203 RRs. As a result, resolvers MUST NOT treat answers with NSEC RRs 204 as negative answers merely because they contain an NSEC. A 205 resolver SHOULD either ignore the NSEC, as a DNSSEC-unaware (or 206 2535-aware) resolver would, or validate the NSEC and check its 207 applicability and interpretation as described in [RFC2535] and 208 [DS]. 210 4. IANA Considerations 212 This document updates the IANA registry for DNS Resource Record 213 Types by assigning types 46, 47, and 48 to the DNSKEY, RRSIG, and 214 NSEC RRs, respectively. 216 Types 24, 25, and 30 (SIG, KEY, and NXT) should be marked as 217 Obsolete. 219 5. Security Considerations 221 The change proposed here does not materially effect security. The 222 implications of trying to use both new and legacy types together 223 are not well understood, and attempts to do so would probably lead 224 to unintended and dangerous results. 226 Changing type codes will leave code paths in legacy resolvers that 227 are never exercised. Unexercised code paths are a frequent source 228 of security holes, largely because those code paths do not get 229 frequent scrutiny. 231 Doing nothing, as described in 3.1, will slow DNSSEC deployment. 232 While this does not decrease security, it also fails to increase 233 it. 235 6. Normative references 237 [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security 238 Extensions", RFC 2065, January 1997. 240 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 241 RFC 2535, March 1999. 243 [DS] Gudmundsson, O., "Delegation Signer Resource Record", 244 draft-ietf-dnsext-delegation-signer-14.txt, work in 245 progress, May 2003. 247 7. Informative References 249 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 250 2671, August 1999. 252 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 253 3225, December 2001. 255 [RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning. 256 Domain Name System (DNS) IANA Considerations. BCP 42, 257 RFC 2929, September 2000. 259 [RFC3445] Massey, D., and S. Rose. Limiting the Scope of the KEY 260 Resource Record (RR). RFC 3445, December 2002. 262 8. Acknowledgments 264 The proposed solution and the analysis of alternatives had many 265 contributors. With apologies to anyone overlooked, those include: 266 Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed Lewis, 267 Bill Manning, and Suzanne Woolf. 269 Thanks to Jakob Schlyter and Mark Andrews for identifying the 270 incompatibility described in section 1.1. 272 In addition to the above, the author would like to thank Scott 273 Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive 274 comments. 276 9. Author's Address 278 Samuel Weiler 279 Network Associates Laboratories 280 15204 Omega Dr., Suite 300 281 Rockville, MD 20850 282 USA 283 weiler@tislabs.com