idnits 2.17.1 draft-ietf-dnsext-dnssec-roadmap-07.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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 283: '... of the algorithm (as one of REQUIRED,...' RFC 2119 keyword, line 284: '... RECOMMENDED, or OPTIONAL)....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (February 4, 2003) is 7745 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) -- Looks like a reference, but probably isn't: 'CAIRN' on line 212 -- Looks like a reference, but probably isn't: 'OPTIN' on line 165 -- Looks like a reference, but probably isn't: 'RENEW' on line 189 -- Looks like a reference, but probably isn't: 'SSH-DNS' on line 318 -- Looks like a reference, but probably isn't: 'IPSEC-DNS' on line 317 == Unused Reference: '20' is defined on line 425, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2535 (ref. '1') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2137 (ref. '3') (Obsoleted by RFC 3007) ** Obsolete normative reference: RFC 2538 (ref. '5') (Obsoleted by RFC 4398) ** Obsolete normative reference: RFC 2541 (ref. '6') (Obsoleted by RFC 4641) ** Obsolete normative reference: RFC 3090 (ref. '9') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2845 (ref. '10') (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 3008 (ref. '12') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 3445 (ref. '16') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions S. Rose 3 Internet-Draft NIST 4 Expires: August 5, 2003 February 4, 2003 6 DNS Security Document Roadmap 7 draft-ietf-dnsext-dnssec-roadmap-07 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 5, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 DNS Security (DNSSEC) technology is composed of extensions to the 39 Domain Name System (DNS) protocol that provide data integrity and 40 authentication to security aware resolvers and applications through 41 the use of cryptographic digital signatures. Several documents exist 42 to describe these extensions and the implementation-specific details 43 regarding specific digital signing schemes. The interrelationship 44 between these different documents is discussed here. A brief 45 overview of what to find in which document and author guidelines for 46 what to include in new DNS Security documents, or revisions to 47 existing documents, is described. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Interrelationship of DNS Security Documents . . . . . . . . . 4 53 3. Relationship of DNS Security Documents to other DNS 54 Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 8 55 4. Recommended Content for new DNS Security Documents . . . . . . 9 56 4.1 Security Related Resource Records . . . . . . . . . . . . . . 9 57 4.2 Digital Signature Algorithm Implementations . . . . . . . . . 9 58 4.3 Refinement of Security Procedures . . . . . . . . . . . . . . 10 59 4.4 The Use of DNS Security Extensions with Other Protocols . . . 10 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 62 Normative References . . . . . . . . . . . . . . . . . . . . . 13 63 Informative References . . . . . . . . . . . . . . . . . . . . 15 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 65 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16 67 1. Introduction 69 This document is intended to provide guidelines for the development 70 of supplemental documents describing security extensions to the 71 Domain Name System (DNS). 73 The main goal of the DNS Security (DNSSEC) extensions is to add data 74 authentication and integrity services to the DNS protocol. These 75 protocol extensions should be differentiated from DNS operational 76 security issues, which are beyond the scope of this effort. DNS 77 Security documents fall into one or possibly more of the following 78 sub-categories: new DNS security resource records, implementation 79 details of specific digital signing algorithms for use in DNS 80 Security and DNS transaction authentication. Since the goal of DNS 81 Security extensions is to become part of the DNS protocol standard, 82 additional documents that seek to refine a portion of the security 83 extensions will be introduced as the specifications progress along 84 the IETF standards track. 86 There is a set of basic guidelines for each sub-category of documents 87 that explains what should be included, what should be considered a 88 protocol extension, and what should be considered an operational 89 issue. Currently, there are at least two documents that fall under 90 operational security considerations that deal specifically with the 91 DNS security extensions: the first is RFC 2541 [6] which deals with 92 the operational side of implementing the security extensions; the 93 other is the CAIRN DNSSEC testbed Internet draft [CAIRN]. These 94 documents should be considered part of the operational side of DNS, 95 but will be addressed as a supplemental part of the DNS Security 96 roadmap. That is not to say that these two documents are not 97 important to securing a DNS zone, but they do not directly address 98 the proposed DNS security extensions. Authors of documents that seek 99 to address the operational concerns of DNS security should be aware 100 of the structure of DNS Security documentation. 102 It is assumed the reader has some knowledge of the Domain Name System 103 [2] and the Domain Name System Security Extensions. 105 2. Interrelationship of DNS Security Documents 107 The DNSSEC set of documents can be partitioned into five main groups 108 as depicted in Figure 1. All of these documents in turn are under 109 the larger umbrella group of DNS base protocol documents. It is 110 possible that some documents fall into more than one of these 111 categories, such as RFC 2535, and should follow the guidelines for 112 the all of the document groups it falls into. However, it is wise to 113 limit the number of "uberdocuments" that try to be everything to 114 everyone. The documents listed in each category are current as to 115 the time of writing. 117 --------------------------------------------------------------------- 119 +--------------------------------+ 120 | | 121 | Base DNS Protocol Docs. | 122 | [RFC1035, RFC2181, etc.] | 123 | | 124 +--------------------------------+ 125 | 126 | 127 | 128 +------------+ +-----------+ +-------------+ 129 | New | | DNSSEC | | New | 130 | Security |----------| protocol |----------| Security | 131 | RRs | | | | Uses | 132 +------------+ | | +-------------+ 133 +-----------+ 134 | 135 | 136 +----------------------+*********************** 137 | * * 138 | * * 139 +------------+ +---------------+ +-*-*-*-*-*-*-*-*-+ 140 | DS | | | | Implementation | 141 | Algorithm | | Transactions | * Notes * 142 | Impl. | | | | | 143 +------------+ +---------------+ +-*-*-*-*-*-*-*-*-+ 145 DNSSEC Document Roadmap 147 --------------------------------------------------------------------- 149 The "DNSSEC protocol" document set refers to the document that makes 150 up the groundwork for adding security to the DNS protocol [1]and 151 updates to this document. RFC 2535 laid out the goals and 152 expectations of DNS Security and the new security-related Resource 153 Records KEY, SIG, DS, and NXT [23]. Expanding from this document, 154 related document groups include the implementation documents of 155 various digital signature algorithms with DNSSEC, and documents 156 further refining the transaction of messages. It is expected that 157 RFC 2535 will be obsoleted by one or more documents that refine the 158 set of security extensions [22], [23], [24]. Documents that seek to 159 modify or clarify the base protocol documents should state so clearly 160 in the introduction of the document (as well as proscribe to the IETF 161 guidelines of RFC/Internet Draft author guidelines). Also, the 162 portions of the specification to be modified should be synopsized in 163 the new document for the benefit of the reader. The "DNSSEC 164 protocol" set includes the documents [1], [11], [12], [9], [14], 165 [15], [21], [16], [OPTIN], [17] and their derivative documents. 167 The "New Security RRs" set refers to the group of documents that seek 168 to add additional Resource Records to the set of base DNS Record 169 types. These new records can be related to securing the DNS protocol 170 [1], [8], or using DNS security for other purposes such as storing 171 certificates [5]. Another related document is [26]. While not 172 detailing a new RR type, it defines a flag bit in the existing KEY 173 RR. This flag bit does not affect the protocol interpretation of the 174 RR, only a possible operational difference. Therefore, this draft is 175 place here and not with the protocol document set. 177 The "DS Algorithm Impl" document set refers to the group of documents 178 that describe how a specific digital signature algorithm is 179 implemented to fit the DNSSEC Resource Record format. Each one of 180 these documents deals with one specific digital signature algorithm. 181 Examples of this set include [4], [5], [25], [19][18] and [13]. 183 The "Transactions" document set refers to the group of documents that 184 deal with the message transaction sequence of security-related DNS 185 operations. The contents and sequence for operations such as dynamic 186 update [3], [11] and transaction signatures [10] are described in 187 this document category. Additional message transaction schemes to 188 support DNSSEC operation would also fall under this group, including 189 secret key establishment [7], [RENEW], and verification. 191 The final document set, "New Security Uses", refers to documents that 192 seek to use proposed DNS Security extensions for other security 193 related purposes. Documents that fall in this category include the 194 use of DNS in the storage and distribution of certificates and 195 individual user public keys (PGP, e-mail, etc.) Some documents in 196 this group may fall beyond the DNSEXT WG scope, but they are included 197 because of their use of the security extensions. The documents in 198 this group should not propose any changes to the DNS protocol to 199 support other protocols; only how existing DNS security records and 200 transactions can be used to support other protocols. Such documents 201 include [SSH-DNS] and [IPSEC-DNS] which deals with storing SSH and 202 IPSec keying information the DNS using new records and utilizing 203 DNSSEC to provide authentication and integrity checking. 205 Lastly, there is a set of documents that should be classified as 206 "Implementation Notes". Because the DNS security extensions are 207 still in the developmental stage, there is an audience for documents 208 that detail the transition and implementation of the security 209 extensions. These have more to do with the practical side of DNS 210 operations, but can also point to places in the protocol 211 specifications that need improvement. An example of this type is the 212 report on the CAIRN DNSSEC testbed [CAIRN] This document was 213 submitted through the DNSOP Working Group at the time of this 214 writing, however the main concern of this document is the 215 implementation and limitations of the DNS security extensions, hence 216 their interest to the DNS security community. The CAIRN draft deals 217 with the implementation of a secure DNS. Authors of documents that 218 deal with the implementation and operational side of the DNSSEC 219 specifications would be advised/encouraged to submit their documents 220 to any other relevant DNS related WG meeting in the problem space. 222 3. Relationship of DNS Security Documents to other DNS Documents 224 The DNS security-related extensions should be considered a subset of 225 the DNS protocol. Therefore, all DNS security-related documents 226 should be seen as a subset of the main DNS architecture documents. 227 It is a good idea for authors of future DNS security documents to be 228 familiar with the contents of these base protocol documents. 230 4. Recommended Content for new DNS Security Documents 232 Documents that seek to make additions or revisions to the DNS 233 protocol to add security should follow common guidelines as to 234 minimum required content and structure. It is the purpose of this 235 document roadmap to establish criteria for content that any new DNS 236 security protocol specifications document should contain. These 237 criteria should be interpreted as a minimum set of information 238 required/needed in a document, any additional information regarding 239 the specific extension should also be included in the document. 240 These criteria are not officially part of the IETF guidelines 241 regarding RFC/Internet Drafts, but should be considered as guidance 242 to promote uniformity to Working Group documents. 244 Since the addition of security to the DNS protocol is now considered 245 a general extension to the DNS protocol, any guideline for the 246 contents of a DNS Security document could be taken as a framework 247 suggestion for the contents of any DNS extension document. The 248 development process of the DNS security extensions could be used as a 249 model framework for any, more general DNS extensions. 251 4.1 Security Related Resource Records 253 Documents describing a new type of DNS Security Resource Record (RR) 254 should contain information describing the structure and use of the 255 new RR type. It is a good idea to only discuss one new type in a 256 document, unless the set of new resource records are closely related 257 or a protocol extension requires the use of more than one new record 258 type. Specifically, each document detailing a new security-related 259 RR type should include the following information: 261 o The format of the new RR type, both "on the wire" (bit format) and 262 ASCII representation (for text zone files), if appropriate; 264 o when and in what section of a DNS query/response this new RR type 265 is to be included; 267 o at which level of the DNS hierarchy this new RR type is to be 268 considered authoritative (i.e. in a zone, in a zone's superzone) 269 and who is authoritative to sign the new RR; 271 4.2 Digital Signature Algorithm Implementations 273 Documents describing the implementation details of a specific digital 274 signature algorithm such as [4] ,[13] (and others as new digital 275 signatures schemes are introduced) for use with DNS Security should 276 include the following information: 278 o The format/encoding of the algorithm's public key for use in a KEY 279 Resource Record; 281 o the acceptable key size for use with the algorithm; 283 o the current known status of the algorithm (as one of REQUIRED, 284 RECOMMENDED, or OPTIONAL). 286 In addition, authors are encouraged to include any necessary 287 description of the algorithm itself, as well as any know/suspected 288 weaknesses as an appendix to the document. This is for reference 289 only, as the goals of the DNSEXT working group is to propose 290 extensions to the DNS protocol, not cryptographic research. 292 4.3 Refinement of Security Procedures 294 This set of documents includes DNS protocol operations that 295 specifically relate to DNS Security, such as DNS secret key 296 establishment [7] and security extensions to pre-existing or 297 proposed DNS operations such as dynamic update [3]. Documents that 298 describe a new set of DNS message transactions, or seek to refine a 299 current series of transactions that make up a DNS operation should 300 include the following information: 302 o The order in which the DNS messages are sent by the operation 303 initiator and target; 305 o the format of these DNS messages; 307 o any required authentication mechanisms for each stage of the 308 operation and the required authority for that mechanism (i.e. 309 zone, host, or some other trusted authority such as a DNS 310 administrator or certificate authority); 312 4.4 The Use of DNS Security Extensions with Other Protocols 314 Because of the flexibility and ubiquity of the DNS, there may exist 315 other Internet protocols and applications that could make use of, or 316 extend, the DNS security protocols. Examples of this type of 317 document include the use of DNS to support IPSEC [IPSEC-DNS], SSH 318 [SSH-DNS] the Public Key Infrastructure (PKI). It is beyond the 319 scope of this roadmap to describe the contents of this class of 320 documents. However, if uses or extensions require the addition or 321 modification of a DNS Resource Record type or DNS query/response 322 transactions, then the guidelines laid out in the previous sections 323 of this document should be adhered to. 325 5. Security Considerations 327 This document provides a roadmap and guidelines for writing DNS 328 Security related documents. This document does not discuss the 329 aspects of the DNS security extensions. The reader should refer to 330 the documents outlined here for the details of the services and 331 shortcomings of DNS security. 333 6. Acknowledgements 335 In addition to the RFCs mentioned in this document, there are also 336 numerous Internet drafts that fall in one or more of the categories 337 of DNS Security documents mentioned above. Depending on where (and 338 if) these documents are on the IETF standards track, the reader may 339 not be able to access these documents through the RFC repositories. 340 All of these documents are "Work in Progress" and are subject to 341 change; therefore a version number is not supplied for the current 342 revision. Some Internet Drafts are in the RFC editor's queue or 343 nearing WG Last Call at the time of writing. These Drafts have been 344 placed in the References section. The drafts below are still subject 345 to agreement in the IETF. 347 o CAIRN: D. Massey, T. Lehman, and E. Lewis. "DNSSEC 348 Implementation in the CAIRN Testbed". draft-ietf-dnsop- 349 dnsseccairn-NN.txt 351 o OPTIN: M. Kosters. "DNSSEC Opt-in for Large Zones" draft- 352 kosters-dnsext-dnssec-opt-in-NN.txt 354 o SSH-DNS: W. Griffin, J. Schlyter. "Using DNS to securely 355 publish SSH key fingerprints" draft-ietf-secsh-dns-NN.txt 357 o IPSEC-DNS: M. Richardson. "A method for storing IPsec keying 358 material in DNS". draft-richardson-ipsec-rr-NN.txt 360 o RENEW: Y. Kamite, M. Nakayama. "TKEY Secret Key Renewal Mode". 361 draft-ietf-dnsext-tkey-renewal-mode-NN.txt 363 Normative References 365 [1] Eastlake, D., "Domain Name System Security Extensions", RFC 366 2535, March 1999. 368 [2] Mockapetris, P., "Domain names - implementation and 369 specification", STD 13, RFC 1035, November 1987. 371 [3] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC 372 2137, April 1997. 374 [4] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 375 (DNS)", RFC 2536, March 1999. 377 [5] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the 378 Domain Name System (DNS)", RFC 2538, March 1999. 380 [6] Eastlake, D., "DNS Security Operational Considerations", RFC 381 2541, March 1999. 383 [7] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 384 2930, September 2000. 386 [8] Eastlake, D., "DNS Request and Transaction Signatures ( 387 SIG(0)s)", RFC 2931, September 2000. 389 [9] Lewis, E., "DNS Security Extension Clarification on Zone 390 Status", RFC 3090, March 2001. 392 [10] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 393 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 394 2845, May 2000. 396 [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic 397 Update", RFC 3007, November 2000. 399 [12] Wellington, B., "Domain Name System Security (DNSSEC) Signing 400 Authority", RFC 3008, April 2000. 402 [13] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 403 System (DNS)", RFC 3110, May 2001. 405 [14] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, 406 December 2001. 408 [15] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver 409 message size requirements", RFC 3226, December 2001. 411 [16] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource 412 Record (RR)", RFC 3445, December 2002. 414 Informative References 416 [17] Austein, R. and D. Atkins, "Threat Analysis of the Domain Name 417 System (Work in Progress)", RFC XXXX. 419 [18] Eastlake, R., "Storage of Diffie-Hellman Keys in the Domain 420 Name System (DNS) (Work in Progress)", RFC XXXX. 422 [19] Eastlake, D. and R. Schroeppel, "Elliptic Curve KEYs in the DNS 423 (Work in Progress)", RFC XXXX. 425 [20] Gundmundsson, O., "Delegation Signer Record in Parent (Work in 426 Progress)", RFC XXXX. 428 [21] Wellington, B., "Redefinition of the DNS AD bit (Work in 429 Progress)", RFC XXXX. 431 [22] Arends, R., Larson, M., Massey, D. and S. Rose, "DNS Security 432 Introduction and Requirements (Work in Progress)", RFC XXXX. 434 [23] Arends, R., Larson, M., Massey, D. and S. Rose, "Resource 435 Records for DNS Security Extensions (Work in Progress)", RFC 436 XXXX. 438 [24] Arends, R., Larson, M., Massey, D. and S. Rose, "Protocol 439 Modifications for the DNS Security Extensions (Work in 440 Progress)", RFC XXXX. 442 [25] Kwan, S., Garg, P., Gilroy, J. and L. Esibov, "GSS Algorithm 443 for TSIG (Work in Progress)", RFC XXXX. 445 [26] Kolkman, O. and J. Schlyter, "KEY RR Key-Signing-Key (KSK) Flag 446 (Work in Progress)", RFC XXXX. 448 Author's Address 450 Scott Rose 451 National Institute for Standards and Technology 452 100 Bureau Drive 453 Gaithersburg, MD 20899-3460 454 USA 456 EMail: scott.rose@nist.gov 458 Full Copyright Statement 460 Copyright (C) The Internet Society (2003). All Rights Reserved. 462 This document and translations of it may be copied and furnished to 463 others, and derivative works that comment on or otherwise explain it 464 or assist in its implementation may be prepared, copied, published 465 and distributed, in whole or in part, without restriction of any 466 kind, provided that the above copyright notice and this paragraph are 467 included on all such copies and derivative works. However, this 468 document itself may not be modified in any way, such as by removing 469 the copyright notice or references to the Internet Society or other 470 Internet organizations, except as needed for the purpose of 471 developing Internet standards in which case the procedures for 472 copyrights defined in the Internet Standards process must be 473 followed, or as required to translate it into languages other than 474 English. 476 The limited permissions granted above are perpetual and will not be 477 revoked by the Internet Society or its successors or assigns. 479 This document and the information contained herein is provided on an 480 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 481 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 482 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 483 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 484 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 486 Acknowledgement 488 Funding for the RFC Editor function is currently provided by the 489 Internet Society.