idnits 2.17.1 draft-srose-dnsext-dnssec-roadmap-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == Mismatching filename: the document gives the document name as 'draft-srose-dnsext-dnssec-roadmap-00', but the file name used is 'draft-srose-dnsext-dnssec-roadmap-01' == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 3) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 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. ** There is 1 instance of too long lines in the document, the longest one being 13 characters in excess of 72. 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 (July 2000) is 8679 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CAIRN' is mentioned on line 207, but not defined == Missing Reference: 'RFC 2119' is mentioned on line 108, but not defined == Missing Reference: 'RFC1035' is mentioned on line 108, but not defined == Missing Reference: 'CLARIFY' is mentioned on line 169, but not defined == Missing Reference: 'AUTH' is mentioned on line 169, but not defined == Missing Reference: 'SIZE' is mentioned on line 169, but not defined == Missing Reference: 'SIG0' is mentioned on line 175, but not defined == Missing Reference: 'UPDATE' is mentioned on line 187, but not defined == Missing Reference: 'TKEY' is mentioned on line 287, but not defined == Missing Reference: 'RFC 2536' is mentioned on line 267, but not defined == Missing Reference: 'RFC 2537' is mentioned on line 267, but not defined ** Obsolete undefined reference: RFC 2537 (Obsoleted by RFC 3110) == Unused Reference: 'RFC1591' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'RFC2181' is defined on line 374, but no explicit reference was found in the text == Unused Reference: 'RFC2541' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'RFC-2119' is defined on line 384, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2537 (Obsoleted by RFC 3110) ** Obsolete normative reference: RFC 2137 (Obsoleted by RFC 3007) ** Obsolete normative reference: RFC 2538 (Obsoleted by RFC 4398) ** Downref: Normative reference to an Not Issued RFC: RFC 541 ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) Summary: 12 errors (**), 0 flaws (~~), 19 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNEXT Working Group S. Rose 3 Internet Draft NIST 4 Expires: January 2001 July 2000 5 Category: Informational 7 DNS Security Document Roadmap 8 ------------------------------ 9 11 Status of this Document 13 This document is an Internet-Draft and is in full 14 conformance with all provisions of Section 10 of RFC2026. 15 Distribution of this document is unlimited. Comments 16 regarding this document should be sent to the author. 18 Internet-Drafts are working documents of the Internet 19 Engineering Task Force (IETF), its areas, and its working 20 groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. Internet-Drafts are 22 draft documents valid for a maximum of six months and may 23 be updated, replaced, or obsoleted by other documents at 24 any time. It is inappropriate to use Internet Drafts as 25 reference material or to cite them other than as "work in 26 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 32 accessed at http://www.ietf.org/shadow.html. 34 Abstract 36 DNS Security (DNSSEC)technology is comprised of 37 extensions to the Domain Name System (DNS) protocol that 38 provide data integrity and authentication to security 39 aware resolvers and applications through the use of 40 cryptographic digital signatures. Several documents 41 exist to describe these extensions and the implementation 42 specific details regarding specific digital signing 43 schemes. The interrelationship between these different 44 documents is discussed here. A brief overview of what to 45 find in which document and author guidelines for what to 46 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 ................ 3 53 3. Relationship of DNS Security Documents to other DNS Docu- 54 ments .......................................................... 6 55 4. Recommended Content for new DNS Security Documents ......... 6 56 4.1 Security Related Resource Records ......................... 6 57 4.2 Digital Signature Algorithm Implementation ................ 7 58 4.3 Refinement of Security Procedures ......................... 7 59 4.4 The Use of DNS Security Extensions with Other Protocols 60 ................................................................ 8 61 5. Security Considerations .................................... 8 62 6. Acknowledgements ........................................... 8 63 7. References ................................................. 9 64 8. Author's Address ........................................... 10 65 Expiration and File Name ....................................... 10 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) protocol extensions is to 74 add data authentication and integrity services to the DNS protocol. 75 These protocol extensions should be differentiated from DNS opera- 76 tional security issues, which are beyond the scope of this effort. 77 DNS Security documents fall into one or possibly more of the follow- 78 ing sub-categories: new DNS security resource records, implementation 79 details of specific digital signing algorithms for use in DNS Secu- 80 rity and Secure DNS transactions. Since the goal of DNS Security 81 extensions is to become part of the DNS protocol standard, additional 82 documents that seek to refine a portion of the security extensions 83 will be introduced as the specifications progress along the IETF 84 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 which deals with the 92 operational side of implementing the security extensions. The other 93 is the CAIRN DNSSEC testbed Internet draft [CAIRN]. These documents 94 should be considered part of the operational side of DNS, but will be 95 addressed as a supplemental part of the DNS Security roadmap. That 96 is not to say that these two documents are not important to securing 97 a DNS zone, but it does not directly address the proposed DNS secu- 98 rity extensions. Authors of documents that seek to address the 99 operational concerns of DNS security should be aware of the structure 100 of DNS Security documentation if they wish to include their documents 101 in the DNSEXT Working Group in addition to the DNS Operations WG. 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC 2119]. It is 106 also assumed the reader has some knowledge of the Domain Name System 107 [RFC1035] and the Domain Name System Security Extensions [RFC2535]. 109 2. Interrelationship of DNS Security Documents 111 The DNSSEC set of documents can be partitioned into five main groups 112 as depicted in Figure 1. All of these documents in turn are under 113 the larger umbrella group of DNS base protocol documents. It is 114 possible that some documents fall into more than one of these 115 categories, such as RFC 2535, and should follow the guidelines for 116 the all of the document groups it falls into. However, it is wise to 117 limit the number of "uberdocuments" that try to be everything to 118 everyone. The documents listed in each category are current as to 119 the time of writing. 121 +--------------------------------+ 122 | | 123 | Base DNS Protocol Docs. | 124 | [RFC1035, RFC2181, etc.] | 125 | | 126 +--------------------------------+ 127 | 128 | 129 | 130 +------------+ +-----------+ +-------------+ 131 | New | | DNSSEC | | New | 132 | Security | <------->| protocol |<-------->| Security | 133 | RRs | | | | Uses | 134 | [RFC2538, | | [RFC2535, | | | 135 | SIG0] | | CLARIFY, | +-------------+ 136 +------------+ | AUTH, | 137 | SIZE ] | 138 +-----------+ 139 | 140 | 141 +----------------------+*********************** 142 | | * 143 | | * 144 +------------+ +---------------+ +-*-*-*-*-*-*-*-*-+ 145 | DS | | | | Implementation | 146 | Algorithm | | Transactions | * Notes * 147 | Impl. | | | | | 148 | [RFC2536, | | [RFC2845, | * [CAIRN] * 149 | RFC2537 | | TKEY] | | | 150 | RFC2539 ] | | | +-*-*-*-*-*-*-*-*-+ 151 +------------+ +---------------+ 152 Figure 1 DNSSEC Document Roadmap 154 The "DNSSEC protocol" document set refers to the document that makes 155 up the groundwork for adding security to the DNS protocol [RFC2535] 156 and updates to this document. RFC 2535 laid out the goals and expec- 157 tations of DNS Security and the new security related Resource Records 158 KEY, SIG, and NXT. Expanding from this document, related document 159 groups include the implementation documents of various digital 160 signature algorithms with DNSSEC, and documents further refining the 161 transaction of messages. It is expected that RFC 2535 will be 162 obseleted by one or more documents that refine the set of security 163 extensions and DNS security transactions. Documents that seek to 164 modify or clarify the base protocol documents should state so clearly 165 in the introduction of the document (as well as proscribe to the IETF 166 guidelines of RFC/Internet Draft author guidelines). Also, the por- 167 tions of the specification to be modified SHOULD be synopsized in the 168 new document for the benefit of the reader. The "DNSSEC protocol" 169 set includes the documents [RFC2535], [CLARIFY], [AUTH], [SIZE] and 170 their derivative documents. 172 The "New Security RRs" set refers to the group of documents that seek 173 to add additional Resource Record to the set of base DNS Record 174 types. These new records can be related to securing the DNS protocol 175 [RFC2535] [SIG0] or using DNS security for other purposes such as 176 storing certificates [RFC2538]. 178 The "DS Algorithm Impl" document set refers to the group of documents 179 that describe how a specific digital signature algorithm is imple- 180 mented to fit the DNSSEC Resource Record format. Each one of these 181 documents deals with one specific digital signature algorithm. Exam- 182 ples of this set include [RFC2536] [RFC2537] and [RFC2539]. 184 The "Transactions" document set refers to the group of documents that 185 deal with the message transaction sequence of security related DNS 186 operations. The contents and sequence for operations such as dynamic 187 update [RFC2137] [UPDATE] and transaction signatures [RFC2845] are 188 described in this document category. Additional message transaction 189 schemes to support DNSSEC operation would also fall under this group, 190 including secret key establishment [TKEY], and verification. 192 The final document set, "New Security Uses", refers to documents that 193 seek to use proposed DNS Security extensions for other security 194 related purposes. Documents that fall in this category include the 195 use of DNS in the distribution of certificates and individual user 196 public keys (PGP, email, etc.). 198 Lastly, there is a set of documents that should be classified as 199 "Implementation Notes". Because the DNS security extensions are 200 still in the developmental stage, there is an audience for documents 201 that detail the transition and implementation of the security exten- 202 sions. These have more to do with the practical side of DNS opera- 203 tions, but can also point to places in the protocol specifications 204 that need improvement. Documents in this set may be offspring of 205 both the DNSEXT and/or DNSOP working groups. Currently, there is 206 only one Internet Draft that falls under this category: The report 207 on the CAIRN DNSSEC testbed [CAIRN]. This document was submitted 208 through the DNSOP working group, however the main concern of this 209 document in the implementation and limitations of the DNS security 210 extensions, hence its interest to the DNS security community. 211 Authors of documents that deal with the implementation and opera- 212 tional side of the DNSSEC specifications would be advised/encouraged 213 to submit their documents to the DNSEXT working group as well. 215 3. Relationship of DNS Security Documents to other DNS Documents 217 The DNS security related extensions should be considered a subset of 218 the DNS protocol. The DNS Security working group of the IETF 219 (DNSSEC) has been absorbed into the larger DNS Extensions working 220 group (DNSEXT). Therefore, all DNS security related documents should 221 be seen as a subset of the main DNS architecture documents. It is a 222 good idea for authors of future DNS security documents to be familiar 223 with the contents of these base protocol documents. 225 4. Recommended Content for new DNS Security Documents 227 Documents that seek to make additions or revisions to the DNS proto- 228 col to add security should follow common guidelines as to minimum 229 required content and structure. It is the purpose of this document 230 roadmap to establish criteria for content that any new DNS security 231 protocol specifications document SHOULD contain. This criteria 232 SHOULD be interpreted as a minimum set of information required/needed 233 in a document, any additional information regarding the specific 234 extension should also be included in the document. These criteria 235 are not officially part of the IETF guidelines regarding RFC/Internet 236 Drafts, but should be considered as guidance to promote uniformity to 237 working group documents. 239 Since the addition of security to the DNS protocol is now considered 240 A general extension to the DNS protocol, any guideline for the con- 241 tents of a DNS Security document could be taken as a suggestion for 242 the contents of any DNS extension document. 244 4.1 Security Related Resource Records 246 Documents describing a new type of DNS Security Resource Record (RR) 247 should contain information describing the structure and use of the 248 new RR type. It is a good idea to only discuss one new type in a 249 document, unless the set of new resource records are closely related 250 or a protocol extensions requires the use of more than one new record 251 type. Specifically: each document detailing a new Security related 252 RR type should include the following information: 254 * The format of the new RR type, both "on the wire" (bit format) and 255 ASCII representation (for text zone files), if appropriate. 257 * When and in what section of a DNS query/response this new RR type 258 is to be included. 260 * At which level of the DNS hierarchy this new RR type is to be 261 considered authoritative (i.e. in a zone, in a zone's superzone) and 262 who is authoritative to sign the new RR. 264 4.2 Digital Signature Algorithm Implementations 266 Documents describing the implementation details of a specific digital 267 signature algorithm such as [RFC 2536, RFC 2537] for use with DNS 268 Security should include the following information: 270 * The format/encoding of the algorithm's public key for use in a 271 KEY Resource Record. 273 * The acceptable key size for use with the algorithm. 275 * The current known status of the algorithm (as one of REQUIRED, 276 RECOMMENDED, or OPTIONAL). 278 In addition, authors are encouraged to include any necessary descrip- 279 tion of the algorithm itself, as well as any know/suspected 280 weaknesses as an appendix to the document. This is for reference 281 only, as the goals of the DNSEXT working group is to propose exten- 282 sions to the DNS protocol, not cryptographic research. 284 4.3 Refinement of Security Procedures 286 This set of documents includes DNS protocol operations that relate to 287 DNS Security specifically such as DNS secret key establishment [TKEY] 288 and security extensions to pre-existing or proposed DNS operations 289 such as dynamic update [RFC2137]. Documents that describe a new set 290 of DNS message transactions, or seek to refine a current series of 291 transaction that make up a DNS operation SHOULD include the following 292 information: 294 * The order in which the DNS messages are sent by the operation ini- 295 tiator and target. 297 * The format of these DNS messages. 299 * Any required authentication mechanisms for each stage of the 300 operation and the required authority for that mechanism (i.e. zone, 301 host, or some other trusted authority such as a DNS administrator or 302 certificate authority). 304 4.4 The Use of DNS Security Extensions with Other Protocols 306 Because of the flexibility and ubiquity of the DNS, there may exist 307 other Internet protocols and applications that could make use of, or 308 extend, the DNS security protocols. Examples of this type of docu- 309 ment include the use of DNS to support the Public Key Infrastructure 310 (PKI). It is beyond the scope of this roadmap to describe the con- 311 tents of this class of documents. However, if uses or extensions 312 require the addition or modification of a DNS Resource Record type or 313 DNS query/response transactions, then the guidelines laid out in the 314 previous sections of this document SHOULD be adhered too. 316 5. Security Considerations 318 This document provides a roadmap and guidelines for writing DNS Secu- 319 rity related documents. The reader should follow all the security 320 procedures and guidelines described in the DNS Security Extensions 321 document [RFC2535]. 323 6. Acknowledgements 325 In addition to the RFCs mentioned in this document, there are also 326 numerous Internet drafts that fall in one or more of the categories 327 of DNS Security documents mentioned above. Depending on where (and 328 if) these documents are on the IETF standards track, the reader may 329 not be able to access these documents through the RFC repositories. 330 For that reason, the version of the Internet drafts that were refer- 331 enced in this document are given below: 333 * SIG0: D. Eastlake. "DNS Request and Transaction Signatures 334 (SIG(0))" . 335 * TKEY: D. Eastlake. "Secret Key Establishment for DNS" . 337 * SIGALG: R. Austein, P. Vixie. "DNS SIGALGOPT". 339 * CLARIFY: E. Lewis. "DNS Security Extension Clarification on Zone 340 Status" 341 * AUTH: B. Wellington. "Domain Name System Security (DNSSEC) 342 Signing Authority" 343 * CAIRN: D. Massey, T. Lehman, and E. Lewis. "DNSSEC Implementa- 344 tion in the CAIRN Testbed". 345 * UPDATE: X. Wang, Y. Huang, and D. Rine. "Secure Online Domain 346 Name System (DNS) Dynamic Update". 348 * SIZE: O. Gudmundsson. "DNSSEC and IPv6 A6 aware server/resolver 349 message size requirements". 351 7. References 353 [RFC2535] D. Eastlake, "Domain Name System Security Extensions", RFC 354 2535, March 1999. 356 [RFC2537] D. Eastlake, "RSA/MD5 KEYs and SIGs in the Domain Name Sys- 357 tem (DNS)", RFC 2537, March 1999. 359 [RFC2536] D. Eastlake, "DSA KEYs and SIGs in the Domain Name System 360 (DNS)", RFC 2536, March 1999. 362 [RFC2137] D. Eastlake, "Secure Domain Name System Dynamic Update", 363 RFC 2137, April 1997. 365 [RFC2539] D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain 366 Name System (DNS)", RFC 2539, March 1999. 368 [RFC2538] D. Eastlake, O. Gudmundsson, "Storing Certificates in the 369 Domain Name System (DNS)", RFC 2538, March 1999. 371 [RFC1591] J. Postal, "Domain Name System Structure and Delegation", 372 RFC 1591, March 1994. 374 [RFC2181] R. Elz, R. Bush, "Clarifications to the DNS Specification", 375 RFC 2181, July 1997. 377 [RFC2541] D. Eastlake, "DNS Security Operational Considerations", RFC 378 541, March 1999. 380 [RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, and B. Wellington. 381 "Secret Key Transaction Authentication for DNS (TSIG)". RFC 2845, 382 May 2000. 384 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", RFC-2119, March 1997. 387 8. Authors' Addresses 388 Scott Rose 389 National Institute for Standards and Technology 390 Gaithersburg, MD 391 Email: scott.rose@nist.gov 393 Expiration and File Name: 395 This draft, titled expires January 2001 397 Full Copyright Statement 399 Copyright (C) The Internet Society (1999). All Rights Reserved. 401 This document and translations of it may be copied and furnished to 402 others, and derivative works that comment on or otherwise explain it 403 or assist in its implementation may be prepared, copied, published 404 and distributed, in whole or in part, without restriction of any 405 kind, provided that the above copyright notice and this paragraph are 406 included on all such copies and derivative works. However, this 407 document itself may not be modified in any way, such as by removing 408 the copyright notice or references to the Internet Society or other 409 Internet organizations, except as needed for the purpose of develop- 410 ing Internet standards in which case the procedures for copyrights 411 defined in the Internet Standards process must be followed, or as 412 required to translate it into languages other than English. 414 The limited permissions granted above are perpetual and will not be 415 revoked by the Internet Society or its successors or assigns. 417 This document and the information contained herein is provided on an 418 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 419 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 420 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 421 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 422 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."