idnits 2.17.1 draft-ietf-dnsext-dnssec-2535typecode-change-00.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 289 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 193: '... old types, SHOULD treat them as unk...' RFC 2119 keyword, line 194: '...lue to them. It MUST NOT use them for...' RFC 2119 keyword, line 196: '...mple, a resolver MUST NOT use DNSKEYs ...' RFC 2119 keyword, line 197: '...Authoritative servers SHOULD NOT serve...' RFC 2119 keyword, line 198: '... those records are included, they MUST...' (2 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 12, 2003) is 7645 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 253, 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. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Samuel Weiler 3 Expires: November 2003 May 12, 2003 5 Legacy Resolver Compatibility for Delegation Signer 6 draft-ietf-dnsext-dnssec-2535typecode-change-00.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 1. Introduction 48 The DNSSEC protocol has been through many iterations whose syntax 49 and semantics are not completely compatible. This has occurred as 50 part of the ordinary process of proposing a protocol, implementing 51 it, testing it in the increasingly complex and diverse environment 52 of the Internet, and refining the definitions of the initial 53 Proposed Standard. In the case of DNSSEC, the process has been 54 complicated by DNS's criticality and wide deployment and the need 55 to add security while minimizing daily operational complexity. 57 A weak area for previous DNS specifications has been lack of detail 58 in specifying resolver behavior, leaving implementors largely on 59 their own to determine many details of resolver function. This, 60 combined with the number of iterations the DNSSEC spec has been 61 through, has resulted in fielded code with a wide variety of 62 behaviors. This variety makes it difficult to predict how a 63 protocol change will be handled by all deployed resolvers. The 64 risk that a change will cause unacceptable or even catastrophic 65 failures makes it difficult to design and deploy a protocol change. 66 One strategy for managing that risk is to structure protocol 67 changes so that existing resolvers can completely ignore input that 68 might confuse them or trigger undesirable failure modes. 70 This document addresses a specific problem caused by Delegation 71 Signer's [DS] introduction of new semantics for the NXT RR that are 72 incompatible with the semantics in [RFC2535]. Answers provided by 73 DS-aware servers can trigger an unacceptable failure mode in some 74 resolvers that implement RFC 2535, which provides a great 75 disincentive to sign zones with DS. The proposed solution allows 76 for the incremental deployment of DS. 78 1.1 The Problem 80 Delegation signer [DS] introduces new semantics for the NXT RR that 81 are incompatible with the semantics in [RFC2535]. In [RFC2535], 82 NXT records were only required to be returned as part of a 83 non-existence proof. In [DS], an unsecure referral returns, in 84 addition to the NS, a proof of non-existence of a DS RR in the form 85 of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was 86 to interpret a response with both an NS and an NXT in the authority 87 section and with NOERROR or NODATA set. Some widely deployed 88 2535-aware resolvers interpret any answer with an NXT as a proof of 89 non-existence of the requested record. This results in unsecure 90 delegations being invisible to 2535-aware resolvers and violates 91 the basic architectural principle that DNSSEC must do no harm -- 92 the signing of zones must not prevent the resolution of unsecured 93 names. 95 2. Possible Solutions 97 This section presents several possible solutions. Section 3 98 recommends one and describes it in more detail. 100 2.1. Change SIG, KEY, and NXT 102 To avoid the problem described above, legacy (RFC2535-aware) 103 resolvers need to be kept from seeing unsecure referrals that 104 include NXT records in the authority section. The simplest way to 105 do that is to change the type codes for SIG, KEY, and NXT. 107 The obvious drawback to this is that new resolvers will not be able 108 to validate zones signed with the old RRs. This problem already 109 exists, however, because of the changes made by DS, and resolvers 110 that understand the old RRs (and have compatibility issues with DS) 111 are far more prevalent than 2535-signed zones. 113 2.2. Change a subset of type codes 115 The observed problem with unsecure referrals could be addressed by 116 changing only the NXT type code or another subset of the type codes 117 that includes NXT. This has the virtue of apparent simplicity, but 118 it risks introducing new problems or not going far enough. It's 119 quite possible that more incompatibilities exist between DS and 120 earlier semantics. Legacy resolvers may also be confused by seeing 121 records they recognize (SIG and KEY) while being unable to find 122 NXTs. Although it may seem unnecessary to fix that which is not 123 obviously broken, it's far cleaner to change all of the type codes 124 at once. This will leave legacy resolvers and tools completely 125 blinded to DNSSEC -- they will see only unknown RRs. 127 2.3. Replace the DO bit 129 Another way to keep legacy resolvers from ever seeing DNSSEC 130 records with DS semantics is to have authoritative servers only 131 send that data to DS-aware resolvers. It's been proposed that 132 assigning a new EDNS0 flag bit to signal DS-awareness (tentatively 133 called "DA"), and having authoritative servers send DNSSEC data 134 only in response to queries with the DA bit set, would accomplish 135 this. This bit would presumably supplant the DO bit described in 136 [RFC3225]. 138 This solution is sufficient only if all 2535-aware resolvers zero 139 out EDNS0 flags that they don't understand. If one passed through 140 the DA bit unchanged, it would still see the new semantics, and it 141 would probably fail to see unsecure delegations. Since it's 142 impractical to know how every DNS implementation handles unknown 143 EDNS0 flags, this is not a universal solution. It could, though, 144 be considered in addition to changing the RR type codes. 146 2.4. Increment the EDNS version 148 Another proposed solution is to increment the EDNS version number 149 as defined in [RFC2671], on the assumption that all existing 150 implementations will reject higher versions than they support, 151 and retain the DO bit as the signal for DNSSEC awareness. This 152 approach has not been tested. 154 2.5. Do nothing 156 There is a large deployed base of DNS resolvers that understand 157 DNSSEC as defined by the standards track [RFC2535] and [RFC2065] 158 and, due to underspecification in those documents, interpret any 159 answer with an NXT as a non-existence proof. So long as that is 160 the case, zone owners will have a strong incentive to not sign any 161 zones that contain unsecure delegations, lest those delegations be 162 invisible to such a large installed base. This will dramatically 163 slow DNSSEC adoption. 165 Unfortunately, without signed zones there's no clear incentive for 166 operators of resolvers to upgrade their software to support the new 167 version of DNSSEC, as defined in [DS]. Historical data suggests 168 that resolvers are rarely upgraded, and that old nameserver code 169 never dies. 171 Rather than wait years for resolvers to be upgraded through natural 172 processes before signing zones with unsecure delegations, 173 addressing this problem with a protocol change will immediately 174 remove the disincentive for signing zones and allow widespread 175 deployment of DNSSEC. 177 3. Protocol changes 179 This document proposes changing the type codes of SIG, KEY, and 180 NXT. This solution is the cleanest and safest, largely because the 181 behavior of resolvers that receive unknown type codes is well 182 understood. This approach has also received the most testing. 184 To avoid operational confusion, it's also necessary to change the 185 mnemonics for these RRs. DNSKEY will be the replacement for KEY, 186 with the mnemonic indicating that these keys are not for 187 application use, per [RFC3445]. RRSIG (Resource Record SIGnature) 188 will replace SIG, and NSEC (Next SECure) will replace NXT. 190 The new types will have exactly the same syntax and semantics as 191 specified for SIG, KEY, and NXT in [RFC2535] and [DS], and they 192 completely replace the old types. A resolver, if it receives the 193 old types, SHOULD treat them as unknown RRs, and SHOULD NOT assign 194 any special semantic value to them. It MUST NOT use them for 195 DNSSEC validations or other DNS operational decision making. For 196 example, a resolver MUST NOT use DNSKEYs to validate SIGs or use 197 KEYs to validate RRSIGs. Authoritative servers SHOULD NOT serve 198 SIG, KEY, or NXT records. If those records are included, they MUST 199 NOT receive special treatment. As an example, if a SIG is included 200 in a signed zone, there MUST be an RRSIG for it. 202 As a clarification to previous documents, NSEC can appear in the 203 authority section of an answer at any time, not just in negative 204 answers. The mere presence of an NSEC record in the answer or 205 authority section of an answer with RCODE=NOERROR, MUST NOT be 206 interpreted as a negative answer. The NSEC must be validated. 208 4. IANA Considerations 210 This document updates the IANA registry for DNS Resource Record 211 Types by assigning types 46, 47, and 48 to the DNSKEY, RRSIG, and 212 NSEC RRs, respectively. 214 Types 24, 25, and 30 (SIG, KEY, and NXT) should be marked as 215 Obsolete. 217 5. Security Considerations 219 The change proposed here does not materially effect security. The 220 implications of trying to use both new and legacy types together 221 are not well understood, and attempts to do so would probably lead 222 to unintended and dangerous results. 224 Changing type codes will leave code paths in legacy resolvers that 225 are never exercised. Unexercised code paths are a frequent source 226 of security holes, largely because those code paths do not get 227 frequent scrutiny. 229 Doing nothing, as described in 3.1, will slow DNSSEC deployment. 230 While this does not decrease security, it also fails to increase 231 it. 233 6. Normative references 235 [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security 236 Extensions", RFC 2065, January 1997. 238 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 239 RFC 2535, March 1999. 241 [DS] Gudmundsson, O., "Delegation Signer Resource Record", 242 draft-ietf-dnsext-delegation-signer-14.txt, work in 243 progress, May 2003. 245 7. Informative References 247 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 248 2671, August 1999. 250 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 251 3225, December 2001. 253 [RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning. 254 Domain Name System (DNS) IANA Considerations. BCP 42, 255 RFC 2929, September 2000. 257 [RFC3445] Massey, D., and S. Rose. Limiting the Scope of the KEY 258 Resource Record (RR). RFC 3445, December 2002. 260 8. Acknowledgments 262 The proposed solution and the analysis of alternatives had many 263 contributors. With apologies to anyone overlooked, those include: 264 Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed Lewis, 265 Bill Manning, and Suzanne Woolf. 267 Thanks to Jakob Schlyter and Mark Andrews for identifying the 268 incompatibility described in section 1.1. 270 In addition to the above, the author would like to thank Scott 271 Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive 272 comments. 274 9. Author's Address 276 Samuel Weiler 277 Network Associates Laboratories 278 15204 Omega Dr., Suite 300 279 Rockville, MD 20850 280 USA 281 weiler@tislabs.com