draft-ietf-dnsext-dnssec-roadmap-07.txt

bind-3.2.

4.  Recommended Content for new DNS Security Documents

   Documents that seek to make additions or revisions to the DNS
   protocol 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.  These
   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
   contents of a DNS Security document could be taken as a framework
   suggestion for the contents of any DNS extension document.  The
   development process of the DNS security extensions could be used as a
   model framework for any, more general DNS extensions.

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 extension requires the use of more than one new record
   type.  Specifically, each document detailing a new security-related
   RR type should include the following information:

   o  The format of the new RR type, both "on the wire" (bit format) and
      ASCII representation (for text zone files), if appropriate;

   o  when and in what section of a DNS query/response this new RR type
      is to be included;

   o  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 [4] ,[13] (and others as new digital
   signatures schemes are introduced) for use with DNS Security should
   include the following information:



Rose                     Expires August 5, 2003                 [Page 9]

Internet-Draft          DNSSEC Document Roadmap            February 2003


   o  The format/encoding of the algorithm's public key for use in a KEY
      Resource Record;

   o  the acceptable key size for use with the algorithm;

   o  the current known status of the algorithm (as one of REQUIRED,
      RECOMMENDED, or OPTIONAL).

   In addition, authors are encouraged to include any necessary
   description 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
   extensions to the DNS protocol, not cryptographic research.

4.3 Refinement of Security Procedures

   This set of documents includes DNS protocol operations that
   specifically relate to DNS Security, such as DNS secret key
   establishment [7]  and security extensions to pre-existing or
   proposed DNS operations such as dynamic update [3].  Documents that
   describe a new set of DNS message transactions, or seek to refine a
   current series of transactions that make up a DNS operation should
   include the following information:

   o  The order in which the DNS messages are sent by the operation
      initiator and target;

   o  the format of these DNS messages;

   o  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
   document include the use of DNS to support IPSEC [IPSEC-DNS], SSH
   [SSH-DNS] the Public Key Infrastructure (PKI).  It is beyond the
   scope of this roadmap to describe the contents 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 to.




Rose                     Expires August 5, 2003                [Page 10]

Internet-Draft          DNSSEC Document Roadmap            February 2003


5. Security Considerations

   This document provides a roadmap and guidelines for writing DNS
   Security related documents.  This document does not discuss the
   aspects of the DNS security extensions.  The reader should refer to
   the documents outlined here for the details of the services and
   shortcomings of DNS security.












































Rose                     Expires August 5, 2003                [Page 11]

Internet-Draft          DNSSEC Document Roadmap            February 2003


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.
   All of these documents are "Work in Progress" and are subject to
   change; therefore a version number is not supplied for the current
   revision.  Some Internet Drafts are in the RFC editor's queue or
   nearing WG Last Call at the time of writing.  These Drafts have been
   placed in the References section.  The drafts below are still subject
   to agreement in the IETF.

   o  CAIRN:  D.  Massey, T.  Lehman, and E.  Lewis.  "DNSSEC
      Implementation in the CAIRN Testbed".  draft-ietf-dnsop-
      dnsseccairn-NN.txt

   o  OPTIN:  M.  Kosters.  "DNSSEC Opt-in for Large Zones"  draft-
      kosters-dnsext-dnssec-opt-in-NN.txt

   o  SSH-DNS:  W.  Griffin, J.  Schlyter.  "Using DNS to securely
      publish SSH key fingerprints"  draft-ietf-secsh-dns-NN.txt

   o  IPSEC-DNS:  M.  Richardson.  "A method for storing IPsec keying
      material in DNS".  draft-richardson-ipsec-rr-NN.txt

   o  RENEW:  Y.  Kamite, M.  Nakayama.  "TKEY Secret Key Renewal Mode".
      draft-ietf-dnsext-tkey-renewal-mode-NN.txt






















Rose                     Expires August 5, 2003                [Page 12]

Internet-Draft          DNSSEC Document Roadmap            February 2003


Normative References

   [1]   Eastlake, D., "Domain Name System Security Extensions", RFC
         2535, March 1999.

   [2]   Mockapetris, P., "Domain names - implementation and
         specification", STD 13, RFC 1035, November 1987.

   [3]   Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
         2137, April 1997.

   [4]   Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
         (DNS)", RFC 2536, March 1999.

   [5]   Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
         Domain Name System (DNS)", RFC 2538, March 1999.

   [6]   Eastlake, D., "DNS Security Operational Considerations", RFC
         2541, March 1999.

   [7]   Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
         2930, September 2000.

   [8]   Eastlake, D., "DNS Request and Transaction Signatures (
         SIG(0)s)", RFC 2931, September 2000.

   [9]   Lewis, E., "DNS Security Extension Clarification on Zone
         Status", RFC 3090, March 2001.

   [10]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
         "Secret Key Transaction Authentication for DNS (TSIG)", RFC
         2845, May 2000.

   [11]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
         Update", RFC 3007, November 2000.

   [12]  Wellington, B., "Domain Name System Security (DNSSEC) Signing
         Authority", RFC 3008, April 2000.

   [13]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
         System (DNS)", RFC 3110, May 2001.

   [14]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
         December 2001.

   [15]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
         message size requirements", RFC 3226, December 2001.




Rose                     Expires August 5, 2003                [Page 13]

Internet-Draft          DNSSEC Document Roadmap            February 2003


   [16]  Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
         Record (RR)", RFC 3445, December 2002.

















































Rose                     Expires August 5, 2003                [Page 14]

Internet-Draft          DNSSEC Document Roadmap            February 2003


Informative References

   [17]  Austein, R. and D. Atkins, "Threat Analysis of the Domain Name
         System (Work in Progress)", RFC XXXX.

   [18]  Eastlake, R., "Storage of Diffie-Hellman Keys in the Domain
         Name System (DNS) (Work in Progress)", RFC XXXX.

   [19]  Eastlake, D. and R. Schroeppel, "Elliptic Curve KEYs in the DNS
         (Work in Progress)", RFC XXXX.

   [20]  Gundmundsson, O., "Delegation Signer Record in Parent (Work in
         Progress)", RFC XXXX.

   [21]  Wellington, B., "Redefinition of the DNS AD bit (Work in
         Progress)", RFC XXXX.

   [22]  Arends, R., Larson, M., Massey, D. and S. Rose, "DNS Security
         Introduction and Requirements (Work in Progress)", RFC XXXX.

   [23]  Arends, R., Larson, M., Massey, D. and S. Rose, "Resource
         Records for DNS Security Extensions (Work in Progress)", RFC
         XXXX.

   [24]  Arends, R., Larson, M., Massey, D. and S. Rose, "Protocol
         Modifications for the DNS Security Extensions (Work in
         Progress)", RFC XXXX.

   [25]  Kwan, S., Garg, P., Gilroy, J. and L. Esibov, "GSS Algorithm
         for TSIG (Work in Progress)", RFC XXXX.

   [26]  Kolkman, O. and J. Schlyter, "KEY RR Key-Signing-Key (KSK) Flag
         (Work in Progress)", RFC XXXX.


Author's Address

   Scott Rose
   National Institute for Standards and Technology
   100 Bureau Drive
   Gaithersburg, MD  20899-3460
   USA

   EMail: [e-mail]







Rose                     Expires August 5, 2003                [Page 15]

Internet-Draft          DNSSEC Document Roadmap            February 2003


Full Copyright Statement

   Copyright (C) The Internet Society (2003).  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
   developing 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
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Rose                     Expires August 5, 2003                [Page 16]