idnits 2.17.1 draft-ietf-dnsext-restrict-key-for-dnssec-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 7) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs 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 148: '...application keys MUST NOT be used to a...' RFC 2119 keyword, line 154: '...ication key data SHOULD not be exchang...' RFC 2119 keyword, line 160: '...4. It MAY be useful for nameservers t...' RFC 2119 keyword, line 176: '...entication. Secure resolvers MUST NOT...' RFC 2119 keyword, line 191: '...lication, but it SHOULD not have an im...' (13 more instances...) -- The abstract seems to indicate that this document updates RFC2535, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 3. DNSSEC zone keys are used to authenticate application keys, but application keys MUST NOT be used to authenticate DNS zone keys. A DNS zone key is either configured as trusted key or authenticated by constructing a chain of trust in the DNS hierarchy. To participate in the chain of trust, a DNS zone needs to exchange zone key information with its parent zone [1]. Application keys are not configured as trusted keys in the DNS and are never part of any DNS chain of trust. Application key data SHOULD not be exchanged with the parent zone. A resolver considers an application key authenticated if it has a valid signature from the local DNS zone keys, but applications could impose additional requirements before the application key is accepted as authentic. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 6. A fault or compromise of a DNS zone key can lead to invalid or forged DNS data, but a fault or compromise of an application key SHOULD have no impact on other DNS data. Incorrectly adding or changing a DNS zone key can invalidate all of the DNS data in zone and in all of its subzones. By using a compromised key, an attacker can forge data from the effected zone and any for any of its sub-zones. A fault or compromise of an application key has implications for that application, but it SHOULD not have an impact on the DNS. Note that application key faults and key compromises can have an impact on the entire DNS if the application key and DNS zone keys are both stored in the KEY record. -- 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 (25 March 2002) is 8065 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) ** Obsolete normative reference: RFC 2535 (ref. '1') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 25 March 2002 4 D. Massey 5 USC/ISI 6 S. Rose 7 NIST 9 Limiting the Scope of the KEY Resource Record 11 draft-ietf-dnsext-restrict-key-for-dnssec-02.txt 13 Status of this Document 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. Distribution of this document 17 is unlimited. Comments regarding this document should be sent to 18 the author. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document limits the Domain Name System KEY resource 37 record to only keys used by the Domain Name System Security 38 Extensions (DNSSEC). The original KEY resource record used 39 sub-typing to store both DNSSEC keys and arbitrary application 40 keys. Storing both DNSSEC and application keys in one record 41 was a mistake. This document removes application keys from 42 the KEY record by redefining the Protocol Octet field in 43 the KEY Resource Record Data. As a result of removing application 44 keys, all but one of the flags in the KEY record become 45 unnecessary and are removed. Three existing application 46 key sub-types are changed to reserved, but the format of 47 the KEY record is not changed. This document updates RFC 48 2535. 50 1 Introduction 52 This document limits the scope the KEY resource record. The KEY 53 resource record was defined in [1] and used resource record sub-typing 54 to hold arbitrary public keys such as Email, IPSEC, DNSSEC, and TLS 55 keys. This document eliminates the existing Email, IPSEC, and TLS 56 sub-types and prohibits the introduction of new sub-types. DNSSEC 57 will be the only allowable sub-type for the KEY record (hence sub-typing 58 is essentially eliminated) and all but one of the KEY record flags 59 are also eliminated. 61 Section 2 presents the motivation for restricting the KEY record 62 and Section 3 defines the revised KEY record. Section 4 and 5 summarize 63 the changes from RFC 2535 and discuss backwards compatibility. It 64 is important to note that this document restricts the use of the 65 KEY record and simplifies the flags, but does not change the definition 66 or use of DNSSEC keys. 68 2 Motivation for Restricting the KEY Record 70 The KEY record RDATA [1] consists of Flags, a Protocol Octet, an 71 Algorithm type, and a Public Key. The Protocol Octet identifies 72 the KEY record sub-type. DNSSEC public keys are stored in the KEY 73 record using a Protocol Octet value of 3. Email, IPSEC, and TLS 74 keys were also stored in the KEY record and used Protocol Octet values 75 of 1,2, and 4 (respectively). Protocol Octet values 5-254 were available 76 for assignment by IANA and values were requested (but not assigned) 77 for applications such as SSH. 79 Any use of sub-typing has inherent limitations. A resolver can not 80 specify the desired sub-type in a DNS query and most DNS operations 81 apply only to resource records sets. For a example, a resolver can 82 not directly request KEY records with a particular sub-type. Instead, 83 the resolver has to request all KEY records associated with a DNS 84 name and then search the set for the desired sub-type. DNSSEC signatures 85 also apply to the set of all KEY resource records associated with 86 the DNS name, regardless of sub-type. 88 In the case of the KEY record, the inherent sub-type limitations 89 are exacerbated since the sub-type is used to distinguish between 90 DNSSEC keys and application keys. DNSSEC keys and application keys 91 differ in virtually every respect and Section 2.1 discusses these 92 differences in more detail. Combining these very different types 93 of keys into a single sub-typed resource record adds unnecessary 94 complexity and increases the potential for implementation and deployment 95 errors. Limited experimental deployment has shown that application 96 keys stored in KEY records are problematic. 98 This document addresses these issues by removing all application keys 99 from the KEY resource record. Note that the scope of this document 100 is strictly limited to the KEY record and this document does not 101 endorse or restrict the storage of application keys in other resource 102 records. 104 2.1 Differences Between DNSSEC and Application Keys 106 DNSSEC keys are an essential part of the DNSSEC protocol and are 107 used by both name servers and resolvers in order to perform DNS tasks. 108 A DNS zone key, used to sign and authenticate RR sets, is the most 109 common example of a DNSSEC key. SIG(0) [3] and TKEY [2] also use 110 DNSSEC keys. 112 Application keys such as Email keys, IPSEC keys, and TLS keys are 113 simply another type data. These keys have no special meaning to 114 a name server or resolver. 116 The following table summarizes some of the differences between DNSSEC 117 keys and Application keys: 119 1. They serve different purposes. 121 2. They are managed by different administrators. 123 3. They are authenticated according to different rules. 125 4. Nameservers use different rules when including them in responses. 127 5. Resolvers process them in different ways. 129 6. Faults/key compromises have different consequences. 131 1. The purpose of a DNSSEC key is to sign resource records associated 132 with a DNS zone (or generate DNS transaction signatures in the case 133 of SIG(0)/TKEY). But the purpose of an application key is specific 134 to the application. Application keys, such as PGP/email, IPSEC, TLS, 135 and SSH keys, are not a mandatory part of any zone and the purpose 136 and proper use of application keys is outside the scope of DNS. 138 2. DNSSEC keys are managed by DNS administrators, but application 139 keys are managed by application administrators. The DNS zone administrator 140 determines the key lifetime, handles any suspected key compromises, 141 and manages any DNSSEC key changes. Likewise, the application administrator 142 is responsible for the same functions for the application keys related 143 to the application. For example, a user typically manages her own 144 PGP key and a server manages its own TLS key. Application key management 145 tasks are outside the scope of DNS administration. 147 3. DNSSEC zone keys are used to authenticate application keys, but 148 application keys MUST NOT be used to authenticate DNS zone keys. 149 A DNS zone key is either configured as trusted key or authenticated 150 by constructing a chain of trust in the DNS hierarchy. To participate 151 in the chain of trust, a DNS zone needs to exchange zone key information 152 with its parent zone [1]. Application keys are not configured as 153 trusted keys in the DNS and are never part of any DNS chain of trust. 154 Application key data SHOULD not be exchanged with the parent zone. 155 A resolver considers an application key authenticated if it has a 156 valid signature from the local DNS zone keys, but applications could 157 impose additional requirements before the application key is accepted 158 as authentic. 160 4. It MAY be useful for nameservers to include DNS zone keys in 161 the additional section of a response, but application keys are typically 162 not useful unless they have been specifically requested. For example, 163 it could be useful to include the isi.edu zone key along with a response 164 that contain the www.isi.edu A record and SIG record. A secure resolver 165 will need the isi.edu zone key in order to check the SIG and authenticate 166 the www.isi.edu A record. It is typical not useful to include the 167 IPSEC, email, and TLS keys along with the A record. Note that by 168 placing application keys in the KEY record, a resolver will need 169 the IPSEC, email, TLS, and other key associated with isi.edu if the 170 resolver intends to authenticate the isi.edu zone key (since signatures 171 only apply to the entire KEY set). 173 5. DNS zone keys require special handling by resolvers, but application 174 keys are treated the same as any other type of DNS data. The DNSSEC 175 keys are of no value to end applications, unless the applications 176 plan to do their own DNS authentication. Secure resolvers MUST NOT 177 use application keys as part of the authentication process. Application 178 keys have no unique value to resolvers and are only useful to the 179 application requesting the key. Note that if sub-types are used 180 to identify the application key, then either the interface to the 181 resolver needs to specify the sub-type or the application needs to 182 be able to accept all KEY records and pick out the desired the sub-type. 184 6. A fault or compromise of a DNS zone key can lead to invalid 185 or forged DNS data, but a fault or compromise of an application key 186 SHOULD have no impact on other DNS data. Incorrectly adding or changing 187 a DNS zone key can invalidate all of the DNS data in zone and in 188 all of its subzones. By using a compromised key, an attacker can 189 forge data from the effected zone and any for any of its sub-zones. 190 A fault or compromise of an application key has implications for 191 that application, but it SHOULD not have an impact on the DNS. Note 192 that application key faults and key compromises can have an impact 193 on the entire DNS if the application key and DNS zone keys are both 194 stored in the KEY record. 196 In summary, DNSSEC keys and application keys differ in most every 197 respect. DNSSEC keys are an essential part of the DNS infrastructure 198 and require special handling by DNS administrators and DNS resolvers. 199 Application keys are simply another type of data and have no special 200 meaning to DNS administrators or resolvers. These two different types 201 of data do not belong in the same resource record. 203 3 Definition of the KEY Resource Record 205 The KEY record uses type 25 and is used as resource record for storing 206 DNSSEC keys. The RDATA for a KEY RR consists of flags, a protocol 207 octet, the algorithm number octet, and the public key itself. The 208 format is as follows: 210 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 211 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | flags | protocol | algorithm | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | / 216 / public key / 217 / / 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 In the flags field, all bits except bit 7 are reserved and SHOULD 221 be zero. If Bit 7 (Zone bit) is set to 1, then the KEY is a DNS 222 Zone key. If Bit 7 is set to 0, the KEY is not a zone key. SIG(0)/TKEY 223 are examples of DNSSEC keys that are not zone keys. 225 The protocol field MUST be set to 3. 227 The algorithm and public key fields are not changed. 229 4 Changes from RFC 2535 KEY Record 231 The KEY RDATA format is not changed. 233 All flags except for the zone key flag are eliminated: 235 o The A/C bits (bits 0 and 1) are eliminated. They SHOULD be 236 set to 0 by the sender and MUST be ignored by the receiver. 238 o The extended flags bit (bit 3) is eliminated. It SHOULD be 239 set to 0 by the sender and MUST be ignored by the receiver. 241 o The host/user bit (bit 6) is eliminated. It SHOULD be set to 242 0 by the sender and MUST be ignored by the receiver. 244 o The zone bit (bit 7) remains unchanged. 246 o The signatory field (bits 12-15) are eliminated by [4]. They 247 SHOULD be set to 0 by the sender and MUST be ignored by the 248 receiver. 250 o Bits 2,4,5,8,9,10,11 remain unchanged. They are reserved, SHOULD 251 be set to zero by the sender, and MUST be ignored by the receiver. 253 Assignment of any future KEY record Flag values requires a standards 254 action. 256 All Protocol Octet values except DNSSEC (3) are eliminated: 258 o Value 1 (Email) is renamed to reserved. 260 o Value 2 (IPSEC) is renamed to reserved. 262 o Value 3 (DNSSEC) is unchanged. 264 o Value 4 (TLS) is renamed to reserved. 266 o Value 5-254 remains unchanged (reserved). 268 o Value 255 (ANY) is renamed to reserved. 270 Name servers and resolvers SHOULD reject any KEY with a Protocol 271 other than 3. Assignment of any future KEY record Protocol Octet 272 values requires a standards action. 274 The algorithm and public key fields are not changed. 276 5 Backward Compatibility 278 DNSSEC zone key records are not change and remain backwards compatible. 279 A properly formatted RFC 2535 zone KEY would have all flag bits, 280 other than the Zone Bit (Bit 7), set to 0 and would have the Protocol 281 Octet set to 3. This remains true under the restricted KEY. 283 DNSSEC non-zone key records (SIG(0)/TKEY keys) are backwards compatible, 284 but the distinction between host and user keys (flag bit 6) is lost. 286 No backwards compatibility is provided for application keys. Any 287 Email, IPSEC, or TLS keys are now deprecated and SHOULD be rejected 288 by name servers and resolvers. Storing application keys in the KEY 289 record created problems such as keys at the apex and large RR sets 290 and some change in the definition and/or usage of the KEY record 291 would have been required even if the approach described here were 292 not adopted. 294 Overall, existing nameservers and resolvers will continue to correctly 295 process KEY records with a sub-type of DNSSEC keys. 297 6 Storing Application Keys in the DNS 299 The scope of this document is strictly limited to the KEY record. 300 This document prohibits storing application keys in the KEY record, 301 but it does not endorse or restrict the storing application keys 302 in other record types. Other documents can describe how DNS handles 303 application keys. 305 7 IANA Consideration 307 RFC 2535 created an IANA registry for DNS KEY Resource Record Protocol 308 Octet values. Values to 1,2,3, 4, and 255 were assigned by RFC 2535 309 and values 5-254 were made available for assignment by IANA. This 310 document makes two sets of changes to this registry. 312 First, this document re-assigns DNS KEY Resource Record Protocol Octet 313 values 1, 2, 4, and 255 to ``reserved''. DNS Key Resource Record 314 Protocol Octet Value 3 remains unchanged as ``DNSSEC''. 316 Second, new values are no longer available for assignment by IANA 317 and this document closes the IANA registry for DNS KEY Resource Record 318 Protocol Octet Values. Assignment of any future KEY Resource Record 319 Protocol Octet values requires a standards action. 321 8 Security Consideration 323 This document eliminates potential security problems that could arise 324 due to the coupling of DNS zone keys and application keys. Prior 325 to the change described in this document, a correctly authenticated 326 KEY set could include both application keys and DNSSEC keys. If 327 one of the application keys is compromised, it could be used as a 328 false zone key to create false DNS signatures (SIG records). Resolvers 329 that do not carefully check the KEY sub-type could believe these 330 false signatures and incorrectly authenticate DNS data. With this 331 change, application keys cannot appear in an authenticated KEY set 332 and this vulnerability is eliminated. 334 The format and correct usage of DNSSEC keys is not changed by this 335 document and no new security considerations are introduced. 337 9 Intellectual Property 339 The IETF takes no position regarding the validity or scope of any 340 intellectual property or other rights that might be claimed to pertain 341 to the implementation or use of the technology described in this 342 document or the extent to which any license under such rights might 343 or might not be available; neither does it represent that it has 344 made any effort to identify any such rights. Information on the 345 IETF's procedures with respect to rights in standards-track and standards- 346 related documentation can be found in BCP-11. 348 Copies of claims of rights made available for publication and any 349 assurances of licenses to be made available, or the result of an 350 attempt made to obtain a general license or permission for the use 351 of such proprietary rights by implementors or users of this specification 352 can be obtained from the IETF Secretariat. 354 The IETF invites any interested party to bring to its attention any 355 copyrights, patents or patent applications, or other proprietary rights 356 which may cover technology that may be required to practice this 357 standard. Please address the information to the IETF Executive Director. 359 10 References (Normative) 361 [1] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, 362 March 1999. 364 [2] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 365 2930, September 2000. 367 [3] Eastlake, D., "DNS Request and Transaction Signatures ( SIG(0)s)", 368 RFC 2931, September 2000. 370 [4] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", 371 RFC 3007, November 2000. 373 11 Author Information 375 Daniel Massey 376 USC Information Sciences Institute 377 3811 North Fairfax Drive, Suite 200 378 Arlington, VA 22203 380 Scott Rose 381 National Institute for Standards and Technology 382 Gaithersburg, MD 384 Full Copyright Statement 386 Copyright (C) The Internet Society (2001). All Rights Reserved. 388 This document and translations of it may be copied and furnished 389 to others, and derivative works that comment on or otherwise explain 390 it or assist in its implementation may be prepared, copied, published 391 and distributed, in whole or in part, without restriction of any 392 kind, provided that the above copy- right notice and this paragraph 393 are included on all such copies and derivative works. However, this 394 document itself may not be modified in any way, such as by removing 395 the copyright notice or references to the Internet Society or other 396 Internet organizations, except as needed for the purpose of developing 397 Internet standards in which case the procedures for copyrights defined 398 in the Internet Standards process must be followed, or as required 399 to translate it into languages other than English. 401 The limited permissions granted above are perpetual and will not 402 be revoked by the Internet Society or its successors or assigns. 404 This document and the information contained herein is provided on 405 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 406 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 407 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 408 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 409 OR FITNESS FOR A PARTICULAR PURPOSE."