idnits 2.17.1 draft-ietf-dnsext-dnssec-roadmap-06.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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 282: '... of the algorithm (as one of REQUIRED,...' RFC 2119 keyword, line 283: '... 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 (September 5, 2002) is 7897 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 211 -- Looks like a reference, but probably isn't: 'OPTIN' on line 166 -- Looks like a reference, but probably isn't: 'RENEW' on line 187 -- Looks like a reference, but probably isn't: 'SSH-DNS' on line 199 -- Looks like a reference, but probably isn't: 'IPSEC-DNS' on line 316 ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' -- Possible downref: Non-RFC (?) normative reference: ref. '22' -- Possible downref: Non-RFC (?) normative reference: ref. '23' -- Possible downref: Non-RFC (?) normative reference: ref. '24' -- Possible downref: Non-RFC (?) normative reference: ref. '25' Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 17 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: March 6, 2003 September 5, 2002 6 DNS Security Document Roadmap 7 draft-ietf-dnsext-dnssec-roadmap-06 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 March 6, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). 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 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 64 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 66 1. Introduction 68 This document is intended to provide guidelines for the development 69 of supplemental documents describing security extensions to the 70 Domain Name System (DNS). 72 The main goal of the DNS Security (DNSSEC) protocol extensions is to 73 add data authentication and integrity services to the DNS protocol. 74 These protocol extensions should be differentiated from DNS 75 operational security issues, which are beyond the scope of this 76 effort. DNS Security documents fall into one or possibly more of the 77 following sub-categories: new DNS security resource records, 78 implementation details of specific digital signing algorithms for use 79 in DNS Security and Secure DNS transactions. Since the goal of DNS 80 Security extensions is to become part of the DNS protocol standard, 81 additional documents that seek to refine a portion of the security 82 extensions will be introduced as the specifications progress along 83 the IETF standards track. 85 There is a set of basic guidelines for each sub-category of documents 86 that explains what should be included, what should be considered a 87 protocol extension, and what should be considered an operational 88 issue. Currently, there are at least two documents that fall under 89 operational security considerations that deal specifically with the 90 DNS security extensions: the first is RFC 2541 [6] which deals with 91 the operational side of implementing the security extensions; the 92 other is the CAIRN DNSSEC testbed Internet draft [CAIRN]. These 93 documents should be considered part of the operational side of DNS, 94 but will be addressed as a supplemental part of the DNS Security 95 roadmap. That is not to say that these two documents are not 96 important to securing a DNS zone, but they do not directly address 97 the proposed DNS security extensions. Authors of documents that seek 98 to address the operational concerns of DNS security should be aware 99 of the structure of DNS Security documentation if they wish to 100 include their documents in the DNSEXT Working Group in addition to 101 the DNS Operations WG. 103 It is assumed the reader has some knowledge of the Domain Name System 104 [2] and the Domain Name System Security Extensions [1]. 106 2. Interrelationship of DNS Security Documents 108 The DNSSEC set of documents can be partitioned into five main groups 109 as depicted in Figure 1. All of these documents in turn are under 110 the larger umbrella group of DNS base protocol documents. It is 111 possible that some documents fall into more than one of these 112 categories, such as RFC 2535, and should follow the guidelines for 113 the all of the document groups it falls into. However, it is wise to 114 limit the number of "uberdocuments" that try to be everything to 115 everyone. The documents listed in each category are current as to 116 the time of writing. 118 --------------------------------------------------------------------- 120 +--------------------------------+ 121 | | 122 | Base DNS Protocol Docs. | 123 | [RFC1035, RFC2181, etc.] | 124 | | 125 +--------------------------------+ 126 | 127 | 128 | 129 +------------+ +-----------+ +-------------+ 130 | New | | DNSSEC | | New | 131 | Security |----------| protocol |----------| Security | 132 | RRs | | | | Uses | 133 +------------+ | | +-------------+ 134 +-----------+ 135 | 136 | 137 +----------------------+*********************** 138 | | * 139 | | * 140 +------------+ +---------------+ +-*-*-*-*-*-*-*-*-+ 141 | DS | | | | Implementation | 142 | Algorithm | | Transactions | * Notes * 143 | Impl. | | | | | 144 +------------+ +---------------+ +-*-*-*-*-*-*-*-*-+ 146 DNSSEC Document Roadmap 148 --------------------------------------------------------------------- 150 The "DNSSEC protocol" document set refers to the document that makes 151 up the groundwork for adding security to the DNS protocol [1]and 152 updates to this document. RFC 2535 laid out the goals and 153 expectations of DNS Security and the new security-related Resource 154 Records KEY, SIG, DS [19] and NXT. Expanding from this document, 155 related document groups include the implementation documents of 156 various digital signature algorithms with DNSSEC, and documents 157 further refining the transaction of messages. It is expected that 158 RFC 2535 will be obsoleted by one or more documents that refine the 159 set of security extensions and DNS security transactions [22], [23], 160 [24]. Documents that seek to modify or clarify the base protocol 161 documents should state so clearly in the introduction of the document 162 (as well as proscribe to the IETF guidelines of RFC/Internet Draft 163 author guidelines). Also, the portions of the specification to be 164 modified should be synopsized in the new document for the benefit of 165 the reader. The "DNSSEC protocol" set includes the documents [1], 166 [11], [12], [9], [14], [15], [21], [20], [OPTIN], [16] and their 167 derivative documents. 169 The "New Security RRs" set refers to the group of documents that seek 170 to add additional Resource Records to the set of base DNS Record 171 types. These new records can be related to securing the DNS protocol 172 [1], [8], or using DNS security for other purposes such as storing 173 certificates [5]. 175 The "DS Algorithm Impl" document set refers to the group of documents 176 that describe how a specific digital signature algorithm is 177 implemented to fit the DNSSEC Resource Record format. Each one of 178 these documents deals with one specific digital signature algorithm. 179 Examples of this set include [4], [5], [25], [18][17] and [13]. 181 The "Transactions" document set refers to the group of documents that 182 deal with the message transaction sequence of security-related DNS 183 operations. The contents and sequence for operations such as dynamic 184 update [3], [11] and transaction signatures [10] are described in 185 this document category. Additional message transaction schemes to 186 support DNSSEC operation would also fall under this group, including 187 secret key establishment [7], [RENEW], and verification. 189 The final document set, "New Security Uses", refers to documents that 190 seek to use proposed DNS Security extensions for other security 191 related purposes. Documents that fall in this category include the 192 use of DNS in the storage and distribution of certificates and 193 individual user public keys (PGP, e-mail, etc.) Some documents in 194 this group may fall beyond the DNSEXT WG scope, but they are included 195 because of their use of the security extensions. The documents in 196 this group should not propose any changes to the DNS protocol to 197 support other protocols; only how existing DNS security records and 198 transactions can be used to support other protocols. Such documents 199 include [SSH-DNS] and [IPSEC-DNS] which deals with storing SSH and 200 IPSec keying information the DNS using new records and utilizing 201 DNSSEC to provide authentication and integrity checking. 203 Lastly, there is a set of documents that should be classified as 204 "Implementation Notes". Because the DNS security extensions are 205 still in the developmental stage, there is an audience for documents 206 that detail the transition and implementation of the security 207 extensions. These have more to do with the practical side of DNS 208 operations, but can also point to places in the protocol 209 specifications that need improvement. Documents in this set may be 210 offspring of both the DNSEXT and/or DNSOP Working Groups. An example 211 of this type is the report on the CAIRN DNSSEC testbed [CAIRN] This 212 document was submitted through the DNSOP Working Group, however the 213 main concern of this document is the implementation and limitations 214 of the DNS security extensions, hence their interest to the DNS 215 security community. The CAIRN draft deals with the implementation of 216 a secure DNS. Authors of documents that deal with the implementation 217 and operational side of the DNSSEC specifications would be advised/ 218 encouraged to submit their documents to the DNSEXT Working Group as 219 well. 221 3. Relationship of DNS Security Documents to other DNS Documents 223 The DNS security-related extensions should be considered a subset of 224 the DNS protocol. The DNS Security Working Group of the IETF 225 (DNSSEC) has been absorbed into the larger DNS Extensions Working 226 Group (DNSEXT). Therefore, all DNS security-related documents should 227 be seen as a subset of the main DNS architecture documents. It is a 228 good idea for authors of future DNS security documents to be familiar 229 with the contents of these base protocol documents. 231 4. Recommended Content for new DNS Security Documents 233 Documents that seek to make additions or revisions to the DNS 234 protocol to add security should follow common guidelines as to 235 minimum required content and structure. It is the purpose of this 236 document roadmap to establish criteria for content that any new DNS 237 security protocol specifications document should contain. These 238 criteria should be interpreted as a minimum set of information 239 required/needed in a document, any additional information regarding 240 the specific extension should also be included in the document. 241 These criteria are not officially part of the IETF guidelines 242 regarding RFC/Internet Drafts, but should be considered as guidance 243 to promote uniformity to Working Group documents. 245 Since the addition of security to the DNS protocol is now considered 246 a general extension to the DNS protocol, any guideline for the 247 contents of a DNS Security document could be taken as a suggestion 248 for the contents of any DNS extension document. 250 4.1 Security Related Resource Records 252 Documents describing a new type of DNS Security Resource Record (RR) 253 should contain information describing the structure and use of the 254 new RR type. It is a good idea to only discuss one new type in a 255 document, unless the set of new resource records are closely related 256 or a protocol extension requires the use of more than one new record 257 type. Specifically, each document detailing a new security-related 258 RR type should include the following information: 260 o The format of the new RR type, both "on the wire" (bit format) and 261 ASCII representation (for text zone files), if appropriate; 263 o when and in what section of a DNS query/response this new RR type 264 is to be included; 266 o at which level of the DNS hierarchy this new RR type is to be 267 considered authoritative (i.e. in a zone, in a zone's superzone) 268 and who is authoritative to sign the new RR; 270 4.2 Digital Signature Algorithm Implementations 272 Documents describing the implementation details of a specific digital 273 signature algorithm such as [4] ,[13] (and others as new digital 274 signatures schemes are introduced) for use with DNS Security should 275 include the following information: 277 o The format/encoding of the algorithm's public key for use in a KEY 278 Resource Record; 280 o the acceptable key size for use with the algorithm; 282 o the current known status of the algorithm (as one of REQUIRED, 283 RECOMMENDED, or OPTIONAL). 285 In addition, authors are encouraged to include any necessary 286 description of the algorithm itself, as well as any know/suspected 287 weaknesses as an appendix to the document. This is for reference 288 only, as the goals of the DNSEXT working group is to propose 289 extensions to the DNS protocol, not cryptographic research. 291 4.3 Refinement of Security Procedures 293 This set of documents includes DNS protocol operations that 294 specifically relate to DNS Security, such as DNS secret key 295 establishment [7] and security extensions to pre-existing or 296 proposed DNS operations such as dynamic update [3]. Documents that 297 describe a new set of DNS message transactions, or seek to refine a 298 current series of transactions that make up a DNS operation should 299 include the following information: 301 o The order in which the DNS messages are sent by the operation 302 initiator and target; 304 o the format of these DNS messages; 306 o any required authentication mechanisms for each stage of the 307 operation and the required authority for that mechanism (i.e. 308 zone, host, or some other trusted authority such as a DNS 309 administrator or certificate authority); 311 4.4 The Use of DNS Security Extensions with Other Protocols 313 Because of the flexibility and ubiquity of the DNS, there may exist 314 other Internet protocols and applications that could make use of, or 315 extend, the DNS security protocols. Examples of this type of 316 document include the use of DNS to support IPSEC [IPSEC-DNS], SSH 317 [SSH-DNS} the Public Key Infrastructure (PKI). It is beyond the 318 scope of this roadmap to describe the contents of this class of 319 documents. However, if uses or extensions require the addition or 320 modification of a DNS Resource Record type or DNS query/response 321 transactions, then the guidelines laid out in the previous sections 322 of this document should be adhered to. 324 5. Security Considerations 326 This document provides a roadmap and guidelines for writing DNS 327 Security related documents. The reader should follow all the 328 security procedures and guidelines described in the DNS Security 329 Extensions document [1]. 331 6. Acknowledgements 333 In addition to the RFCs mentioned in this document, there are also 334 numerous Internet drafts that fall in one or more of the categories 335 of DNS Security documents mentioned above. Depending on where (and 336 if) these documents are on the IETF standards track, the reader may 337 not be able to access these documents through the RFC repositories. 338 All of these documents are "Work in Progress" and are subject to 339 change; therefore a version number is not supplied for the current 340 revision. Some Internet Drafts are in the RFC editor's queue or 341 nearing WG Last Call at the time of writing. These Drafts have been 342 placed in the References section. The drafts below are still subject 343 to agreement in the IETF. 345 o CAIRN: D. Massey, T. Lehman, and E. Lewis. "DNSSEC 346 Implementation in the CAIRN Testbed". draft-ietf-dnsop- 347 dnsseccairn-NN.txt 349 o OPTIN: M. Kosters. "DNSSEC Opt-in for Large Zones" draft- 350 kosters-dnsext-dnssec-opt-in-NN.txt 352 o SSH-DNS: W. Griffin, J. Schlyter. "Using DNS to securely 353 publish SSH key fingerprints" draft-ietf-secsh-dns-NN.txt 355 o IPSEC-DNS: M. Richardson. "A method for storing IPsec keying 356 material in DNS". draft-richardson-ipsec-rr-NN.txt 358 o RENEW: Y. Kamite, M. Nakayama. "TKEY Secret Key Renewal Mode". 359 draft-ietf-dnsext-tkey-renewal-mode-NN.txt 361 References 363 [1] Eastlake, D., "Domain Name System Security Extensions", RFC 364 2535, March 1999. 366 [2] Mockapetris, P., "Domain names - implementation and 367 specification", STD 13, RFC 1035, November 1987. 369 [3] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC 370 2137, April 1997. 372 [4] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 373 (DNS)", RFC 2536, March 1999. 375 [5] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the 376 Domain Name System (DNS)", RFC 2538, March 1999. 378 [6] Eastlake, D., "DNS Security Operational Considerations", RFC 379 2541, March 1999. 381 [7] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 382 2930, September 2000. 384 [8] Eastlake, D., "DNS Request and Transaction Signatures ( 385 SIG(0)s)", RFC 2931, September 2000. 387 [9] Lewis, E., "DNS Security Extension Clarification on Zone 388 Status", RFC 3090, March 2001. 390 [10] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 391 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 392 2845, May 2000. 394 [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic 395 Update", RFC 3007, November 2000. 397 [12] Wellington, B., "Domain Name System Security (DNSSEC) Signing 398 Authority", RFC 3008, April 2000. 400 [13] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 401 System (DNS)", RFC 3110, May 2001. 403 [14] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, 404 December 2001. 406 [15] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver 407 message size requirements", RFC 3226, December 2001. 409 [16] Austein, R. and D. Atkins, "Threat Analysis of the Domain Name 410 System (Work in Progress)", RFC XXXX. 412 [17] Eastlake, R., "Storage of Diffie-Hellman Keys in the Domain 413 Name System (DNS) (Work in Progress)", RFC XXXX. 415 [18] Eastlake, D. and R. Schroeppel, "Elliptic Curve KEYs in the DNS 416 (Work in Progress)", RFC XXXX. 418 [19] Gundmundsson, O., "Delegation Signer Record in Parent (Work in 419 Progress)", RFC XXXX. 421 [20] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource 422 Record (Work in Progress)", RFC XXXX. 424 [21] Wellington, B., "Redefinition of the DNS AD bit (Work in 425 Progress)", RFC XXXX. 427 [22] Arends, R., Larson, M., Massey, D. and S. Rose, "DNS Security 428 Introduction and Requirements (Work in Progress)", RFC XXXX. 430 [23] Arends, R., Larson, M., Massey, D. and S. Rose, "DNS Security 431 Introduction and Requirements (Work in Progress)", RFC XXXX. 433 [24] Arends, R., Larson, M., Massey, D. and S. Rose, "DNS Security 434 Introduction and Requirements (Work in Progress)", RFC XXXX. 436 [25] Kwan, S., Garg, P., Gilroy, J. and L. Esibov, "GSS Algorithm 437 for TSIG (Work in Progress)", RFC XXXX. 439 Author's Address 441 Scott Rose 442 National Institute for Standards and Technology 443 100 Bureau Drive 444 Gaithersburg, MD 20899-3460 445 USA 447 EMail: scott.rose@nist.gov 449 Full Copyright Statement 451 Copyright (C) The Internet Society (2002). All Rights Reserved. 453 This document and translations of it may be copied and furnished to 454 others, and derivative works that comment on or otherwise explain it 455 or assist in its implementation may be prepared, copied, published 456 and distributed, in whole or in part, without restriction of any 457 kind, provided that the above copyright notice and this paragraph are 458 included on all such copies and derivative works. However, this 459 document itself may not be modified in any way, such as by removing 460 the copyright notice or references to the Internet Society or other 461 Internet organizations, except as needed for the purpose of 462 developing Internet standards in which case the procedures for 463 copyrights defined in the Internet Standards process must be 464 followed, or as required to translate it into languages other than 465 English. 467 The limited permissions granted above are perpetual and will not be 468 revoked by the Internet Society or its successors or assigns. 470 This document and the information contained herein is provided on an 471 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 472 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 473 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 474 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 475 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 477 Acknowledgement 479 Funding for the RFC Editor function is currently provided by the 480 Internet Society.