From 2a0b1b6c6d8eb3602546cbdcb9fada4a22f8f7bf Mon Sep 17 00:00:00 2001 From: Andreas Gustafsson Date: Fri, 18 Aug 2000 19:37:14 +0000 Subject: [PATCH] added draft-ietf-dnsext-dnssec-roadmap-00.txt --- .../draft-ietf-dnsext-dnssec-roadmap-00.txt | 661 ++++++++++++++++++ 1 file changed, 661 insertions(+) create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-roadmap-00.txt diff --git a/doc/draft/draft-ietf-dnsext-dnssec-roadmap-00.txt b/doc/draft/draft-ietf-dnsext-dnssec-roadmap-00.txt new file mode 100644 index 0000000000..22ec053a35 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-roadmap-00.txt @@ -0,0 +1,661 @@ + + + + + + +DNEXT Working Group S. Rose +Internet Draft NIST +Expires: February 2001 August 2000 +Category: Informational + + + + + DNS Security Document Roadmap + ------------------------------ + + + +Status of this Document + + This document is an Internet-Draft and is in full + conformance with all provisions of Section 10 of RFC2026. + Distribution of this document is unlimited. Comments + regarding this document should be sent to the author. + + Internet-Drafts are working documents of the Internet + Engineering Task Force (IETF), its areas, and its working + groups. Note that other groups may also distribute + working documents as Internet-Drafts. Internet-Drafts are + draft documents valid for a maximum of six months and may + be updated, replaced, or obsoleted by other documents at + any time. It is inappropriate to use Internet Drafts as + reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be + accessed at http://www.ietf.org/shadow.html. + + +Abstract + + DNS Security (DNSSEC)technology is composed of extensions + to the Domain Name System (DNS) protocol that provide + data integrity and authentication to security aware + resolvers and applications through the use of + cryptographic digital signatures. Several documents + exist to describe these extensions and the implementation + specific details regarding specific digital signing + schemes. The interrelationship between these different + documents is discussed here. A brief overview of what to + + + +Rose [Page 1] + + + + + +INTERNET-DRAFT DNS Security Document Roadmap August 2000 + + + find in which document and author guidelines for what to + include in new DNS Security documents, or revisions to + existing documents, is described. + + + + + + + + + + 1. Introduction ............................................... 3 + 2. Interrelationship of DNS Security Documents ................ 3 + 3. Relationship of DNS Security Documents to other DNS Docu- + ments .......................................................... 6 + 4. Recommended Content for new DNS Security Documents ......... 6 + 4.1 Security Related Resource Records ......................... 6 + 4.2 Digital Signature Algorithm Implementation ................ 7 + 4.3 Refinement of Security Procedures ......................... 7 + 4.4 The Use of DNS Security Extensions with Other Protocols + ................................................................ 8 + 5. Security Considerations .................................... 8 + 6. Acknowledgements ........................................... 8 + 7. References ................................................. 9 + 8. Author's Address ........................................... 10 + Expiration and File Name ....................................... 10 + + + + + + + + + + + + + + + + + + + + + + + + +Rose [Page 2] + + + + + +INTERNET-DRAFT DNS Security Document Roadmap August 2000 + + +1. Introduction + + This document is intended to provide guidelines for the development + of supplemental documents describing security extensions to the + Domain Name System (DNS). + + The main goal of the DNS Security (DNSSEC) protocol extensions is to + add data authentication and integrity services to the DNS protocol. + These protocol extensions should be differentiated from DNS opera- + tional security issues, which are beyond the scope of this effort. + DNS Security documents fall into one or possibly more of the follow- + ing sub-categories: new DNS security resource records, implementation + details of specific digital signing algorithms for use in DNS Secu- + rity and Secure DNS transactions. Since the goal of DNS Security + extensions is to become part of the DNS protocol standard, additional + documents that seek to refine a portion of the security extensions + will be introduced as the specifications progress along the IETF + standards track. + + There is a set of basic guidelines for each sub-category of documents + that explains what should be included, what should be considered a + protocol extension, and what should be considered an operational + issue. Currently, there are at least two documents that fall under + operational security considerations that deal specifically with the + DNS security extensions: The first is RFC 2541 which deals with the + operational side of implementing the security extensions. The other + is the CAIRN DNSSEC testbed Internet draft [CAIRN]. These documents + should be considered part of the operational side of DNS, but will be + addressed as a supplemental part of the DNS Security roadmap. That + is not to say that these two documents are not important to securing + a DNS zone, but it does not directly address the proposed DNS secu- + rity extensions. Authors of documents that seek to address the + operational concerns of DNS security should be aware of the structure + of DNS Security documentation if they wish to include their documents + in the DNSEXT Working Group in addition to the DNS Operations WG. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC 2119]. It is + also assumed the reader has some knowledge of the Domain Name System + [RFC1035] and the Domain Name System Security Extensions [RFC2535]. + + +2. Interrelationship of DNS Security Documents + + The DNSSEC set of documents can be partitioned into five main groups + as depicted in Figure 1. All of these documents in turn are under + the larger umbrella group of DNS base protocol documents. It is + + + +Rose [Page 3] + + + + + +INTERNET-DRAFT DNS Security Document Roadmap August 2000 + + + possible that some documents fall into more than one of these + categories, such as RFC 2535, and should follow the guidelines for + the all of the document groups it falls into. However, it is wise to + limit the number of "uberdocuments" that try to be everything to + everyone. The documents listed in each category are current as to + the time of writing. + + + +--------------------------------+ + | | + | Base DNS Protocol Docs. | + | [RFC1035, RFC2181, etc.] | + | | + +--------------------------------+ + | + | + | + +------------+ +-----------+ +-------------+ + | New | | DNSSEC | | New | + | Security | <------->| protocol |<-------->| Security | + | RRs | | | | Uses | + | [RFC2538, | | [RFC2535, | | | + | SIG0 NO] | | CLARIFY, | +-------------+ + +------------+ | AUTH, | + | SIZE ] | + +-----------+ + | + | + +----------------------+*********************** + | | * + | | * + +------------+ +---------------+ +-*-*-*-*-*-*-*-*-+ + | DS | | | | Implementation | + | Algorithm | | Transactions | * Notes * + | Impl. | | | | | + | [RFC2536, | | [RFC2845, | * [CAIRN] * + | RFC2537 | | TKEY] | | | + | RFC2539 | | | * * + | GSS-TSIG] | | | +-*-*-*-*-*-*-*-*-+ + +------------+ +---------------+ + Figure 1 DNSSEC Document Roadmap + + + The "DNSSEC protocol" document set refers to the document that makes + up the groundwork for adding security to the DNS protocol [RFC2535] + and updates to this document. RFC 2535 laid out the goals and expec- + tations of DNS Security and the new security related Resource Records + KEY, SIG, and NXT. Expanding from this document, related document + + + +Rose [Page 4] + + + + + +INTERNET-DRAFT DNS Security Document Roadmap August 2000 + + + groups include the implementation documents of various digital signa- + ture algorithms with DNSSEC, and documents further refining the tran- + saction of messages. It is expected that RFC 2535 will be obseleted + by one or more documents that refine the set of security extensions + and DNS security transactions. Documents that seek to modify or + clarify the base protocol documents should state so clearly in the + introduction of the document (as well as proscribe to the IETF guide- + lines of RFC/Internet Draft author guidelines). Also, the portions + of the specification to be modified SHOULD be synopsized in the new + document for the benefit of the reader. The "DNSSEC protocol" set + includes the documents [RFC2535], [CLARIFY], [AUTH], [SIZE] and their + derivative documents. + + The "New Security RRs" set refers to the group of documents that seek + to add additional Resource Record to the set of base DNS Record + types. These new records can be related to securing the DNS protocol + [RFC2535] [SIG0] [NO] or using DNS security for other purposes such + as storing certificates [RFC2538]. + + The "DS Algorithm Impl" document set refers to the group of documents + that describe how a specific digital signature algorithm is imple- + mented to fit the DNSSEC Resource Record format. Each one of these + documents deals with one specific digital signature algorithm. Exam- + ples of this set include [RFC2536] [RFC2537] [RFC2539] and [GSS- + TSIG]. + + The "Transactions" document set refers to the group of documents that + deal with the message transaction sequence of security related DNS + operations. The contents and sequence for operations such as dynamic + update [RFC2137] [UPDATE] and transaction signatures [RFC2845] are + described in this document category. Additional message transaction + schemes to support DNSSEC operation would also fall under this group, + including secret key establishment [TKEY], and verification. + + The final document set, "New Security Uses", refers to documents that + seek to use proposed DNS Security extensions for other security + related purposes. Documents that fall in this category include the + use of DNS in the distribution of certificates and individual user + public keys (PGP, email, etc.). + + Lastly, there is a set of documents that should be classified as + "Implementation Notes". Because the DNS security extensions are + still in the developmental stage, there is an audience for documents + that detail the transition and implementation of the security exten- + sions. These have more to do with the practical side of DNS opera- + tions, but can also point to places in the protocol specifications + that need improvement. Documents in this set may be offspring of + both the DNSEXT and/or DNSOP working groups. Currently, there is + + + +Rose [Page 5] + + + + + +INTERNET-DRAFT DNS Security Document Roadmap August 2000 + + + only one Internet Draft that falls under this category: The report + on the CAIRN DNSSEC testbed [CAIRN]. This document was submitted + through the DNSOP working group, however the main concern of this + document in the implementation and limitations of the DNS security + extensions, hence its interest to the DNS security community. + Authors of documents that deal with the implementation and opera- + tional side of the DNSSEC specifications would be advised/encouraged + to submit their documents to the DNSEXT working group as well. + + +3. Relationship of DNS Security Documents to other DNS Documents + + The DNS security related extensions should be considered a subset of + the DNS protocol. The DNS Security working group of the IETF + (DNSSEC) has been absorbed into the larger DNS Extensions working + group (DNSEXT). Therefore, all DNS security related documents should + be seen as a subset of the main DNS architecture documents. It is a + good idea for authors of future DNS security documents to be familiar + with the contents of these base protocol documents. + + +4. Recommended Content for new DNS Security Documents + + Documents that seek to make additions or revisions to the DNS proto- + col to add security should follow common guidelines as to minimum + required content and structure. It is the purpose of this document + roadmap to establish criteria for content that any new DNS security + protocol specifications document SHOULD contain. This criteria + SHOULD be interpreted as a minimum set of information required/needed + in a document, any additional information regarding the specific + extension should also be included in the document. These criteria + are not officially part of the IETF guidelines regarding RFC/Internet + Drafts, but should be considered as guidance to promote uniformity to + working group documents. + + Since the addition of security to the DNS protocol is now considered + A general extension to the DNS protocol, any guideline for the con- + tents of a DNS Security document could be taken as a suggestion for + the contents of any DNS extension document. + + +4.1 Security Related Resource Records + + Documents describing a new type of DNS Security Resource Record (RR) + should contain information describing the structure and use of the + new RR type. It is a good idea to only discuss one new type in a + document, unless the set of new resource records are closely related + or a protocol extensions requires the use of more than one new record + + + +Rose [Page 6] + + + + + +INTERNET-DRAFT DNS Security Document Roadmap August 2000 + + + type. Specifically: each document detailing a new Security related + RR type should include the following information: + + * The format of the new RR type, both "on the wire" (bit format) and + ASCII representation (for text zone files), if appropriate. + + * When and in what section of a DNS query/response this new RR type + is to be included. + + * At which level of the DNS hierarchy this new RR type is to be + considered authoritative (i.e. in a zone, in a zone's superzone) and + who is authoritative to sign the new RR. + + +4.2 Digital Signature Algorithm Implementations + + Documents describing the implementation details of a specific digital + signature algorithm such as [RFC 2536, RFC 2537] for use with DNS + Security should include the following information: + + * The format/encoding of the algorithm's public key for use in a + KEY Resource Record. + + * The acceptable key size for use with the algorithm. + + * The current known status of the algorithm (as one of REQUIRED, + RECOMMENDED, or OPTIONAL). + + In addition, authors are encouraged to include any necessary descrip- + tion of the algorithm itself, as well as any know/suspected + weaknesses as an appendix to the document. This is for reference + only, as the goals of the DNSEXT working group is to propose exten- + sions to the DNS protocol, not cryptographic research. + + +4.3 Refinement of Security Procedures + + This set of documents includes DNS protocol operations that relate to + DNS Security specifically such as DNS secret key establishment [TKEY] + and security extensions to pre-existing or proposed DNS operations + such as dynamic update [RFC2137]. Documents that describe a new set + of DNS message transactions, or seek to refine a current series of + transaction that make up a DNS operation SHOULD include the following + information: + + * The order in which the DNS messages are sent by the operation ini- + tiator and target. + + + + +Rose [Page 7] + + + + + +INTERNET-DRAFT DNS Security Document Roadmap August 2000 + + + * The format of these DNS messages. + + * Any required authentication mechanisms for each stage of the + operation and the required authority for that mechanism (i.e. zone, + host, or some other trusted authority such as a DNS administrator or + certificate authority). + + +4.4 The Use of DNS Security Extensions with Other Protocols + + Because of the flexibility and ubiquity of the DNS, there may exist + other Internet protocols and applications that could make use of, or + extend, the DNS security protocols. Examples of this type of docu- + ment include the use of DNS to support the Public Key Infrastructure + (PKI). It is beyond the scope of this roadmap to describe the con- + tents of this class of documents. However, if uses or extensions + require the addition or modification of a DNS Resource Record type or + DNS query/response transactions, then the guidelines laid out in the + previous sections of this document SHOULD be adhered too. + + +5. Security Considerations + + This document provides a roadmap and guidelines for writing DNS Secu- + rity related documents. The reader should follow all the security + procedures and guidelines described in the DNS Security Extensions + document [RFC2535]. + + +6. Acknowledgements + + In addition to the RFCs mentioned in this document, there are also + numerous Internet drafts that fall in one or more of the categories + of DNS Security documents mentioned above. Depending on where (and + if) these documents are on the IETF standards track, the reader may + not be able to access these documents through the RFC repositories. + For that reason, the version of the Internet drafts that were refer- + enced in this document are given below: + + * SIG0: D. Eastlake. "DNS Request and Transaction Signatures + (SIG(0))" . + * TKEY: D. Eastlake. "Secret Key Establishment for DNS" . + * SIGALG: R. Austein, P. Vixie. "DNS SIGALGOPT". + * CLARIFY: E. Lewis. "DNS Security Extension Clarification on Zone + Status" + * AUTH: B. Wellington. "Domain Name System Security (DNSSEC) + + + +Rose [Page 8] + + + + + +INTERNET-DRAFT DNS Security Document Roadmap August 2000 + + + Signing Authority" + * CAIRN: D. Massey, T. Lehman, and E. Lewis. "DNSSEC Implementa- + tion in the CAIRN Testbed". + * UPDATE: X. Wang, Y. Huang, and D. Rine. "Secure Online Domain + Name System (DNS) Dynamic Update". + * SIZE: O. Gudmundsson. "DNSSEC and IPv6 A6 aware server/resolver + message size requirements". + * GSS-TSIG: S. Kwan, P. Garg, J. Gilroy, and L. Esibov. "GSS + Algorithm for TSIG (GSS-TSIG)". + * NO: S. A. Josefsson. "Authenticating Denial of Existence in DNS + with Minimum Disclosure". + + +7. References + + [RFC2535] D. Eastlake, "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [RFC2537] D. Eastlake, "RSA/MD5 KEYs and SIGs in the Domain Name Sys- + tem (DNS)", RFC 2537, March 1999. + + [RFC2536] D. Eastlake, "DSA KEYs and SIGs in the Domain Name System + (DNS)", RFC 2536, March 1999. + + [RFC2137] D. Eastlake, "Secure Domain Name System Dynamic Update", + RFC 2137, April 1997. + + [RFC2539] D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain + Name System (DNS)", RFC 2539, March 1999. + + [RFC2538] D. Eastlake, O. Gudmundsson, "Storing Certificates in the + Domain Name System (DNS)", RFC 2538, March 1999. + + [RFC1591] J. Postal, "Domain Name System Structure and Delegation", + RFC 1591, March 1994. + + [RFC2181] R. Elz, R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [RFC2541] D. Eastlake, "DNS Security Operational Considerations", RFC + 541, March 1999. + + [RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, and B. Wellington. + "Secret Key Transaction Authentication for DNS (TSIG)". RFC 2845, + May 2000. + + [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate + + + +Rose [Page 9] + + + + + +INTERNET-DRAFT DNS Security Document Roadmap August 2000 + + + Requirement Levels", RFC-2119, March 1997. + + + + +8. Authors' Addresses + + Scott Rose + National Institute for Standards and Technology + Gaithersburg, MD + Email: scott.rose@nist.gov + + + +Expiration and File Name: + + This draft, titled expires +February 2001 + + + +Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of develop- + ing Internet standards in which case the procedures for copyrights + defined in the Internet Standards process must be followed, or as + required to translate it into languages other than English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- + CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." + + + + + +Rose [Page 10] + + + + + +INTERNET-DRAFT DNS Security Document Roadmap August 2000 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rose [Page 11] + +