< draft-ietf-dnsext-dnssec-roadmap-06.txt   draft-ietf-dnsext-dnssec-roadmap-07.txt >
DNS Extensions S. Rose DNS Extensions S. Rose
Internet-Draft NIST Internet-Draft NIST
Expires: March 6, 2003 September 5, 2002 Expires: August 5, 2003 February 4, 2003
DNS Security Document Roadmap DNS Security Document Roadmap
draft-ietf-dnsext-dnssec-roadmap-06 draft-ietf-dnsext-dnssec-roadmap-07
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 6, 2003. This Internet-Draft will expire on August 5, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
DNS Security (DNSSEC) technology is composed of extensions to the DNS Security (DNSSEC) technology is composed of extensions to the
Domain Name System (DNS) protocol that provide data integrity and Domain Name System (DNS) protocol that provide data integrity and
authentication to security aware resolvers and applications through authentication to security aware resolvers and applications through
the use of cryptographic digital signatures. Several documents exist the use of cryptographic digital signatures. Several documents exist
to describe these extensions and the implementation-specific details to describe these extensions and the implementation-specific details
regarding specific digital signing schemes. The interrelationship regarding specific digital signing schemes. The interrelationship
between these different documents is discussed here. A brief between these different documents is discussed here. A brief
skipping to change at page 2, line 18 skipping to change at page 2, line 18
2. Interrelationship of DNS Security Documents . . . . . . . . . 4 2. Interrelationship of DNS Security Documents . . . . . . . . . 4
3. Relationship of DNS Security Documents to other DNS 3. Relationship of DNS Security Documents to other DNS
Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Recommended Content for new DNS Security Documents . . . . . . 9 4. Recommended Content for new DNS Security Documents . . . . . . 9
4.1 Security Related Resource Records . . . . . . . . . . . . . . 9 4.1 Security Related Resource Records . . . . . . . . . . . . . . 9
4.2 Digital Signature Algorithm Implementations . . . . . . . . . 9 4.2 Digital Signature Algorithm Implementations . . . . . . . . . 9
4.3 Refinement of Security Procedures . . . . . . . . . . . . . . 10 4.3 Refinement of Security Procedures . . . . . . . . . . . . . . 10
4.4 The Use of DNS Security Extensions with Other Protocols . . . 10 4.4 The Use of DNS Security Extensions with Other Protocols . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Normative References . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 Informative References . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document is intended to provide guidelines for the development This document is intended to provide guidelines for the development
of supplemental documents describing security extensions to the of supplemental documents describing security extensions to the
Domain Name System (DNS). Domain Name System (DNS).
The main goal of the DNS Security (DNSSEC) protocol extensions is to The main goal of the DNS Security (DNSSEC) extensions is to add data
add data authentication and integrity services to the DNS protocol. authentication and integrity services to the DNS protocol. These
These protocol extensions should be differentiated from DNS protocol extensions should be differentiated from DNS operational
operational security issues, which are beyond the scope of this security issues, which are beyond the scope of this effort. DNS
effort. DNS Security documents fall into one or possibly more of the Security documents fall into one or possibly more of the following
following sub-categories: new DNS security resource records, sub-categories: new DNS security resource records, implementation
implementation details of specific digital signing algorithms for use details of specific digital signing algorithms for use in DNS
in DNS Security and Secure DNS transactions. Since the goal of DNS Security and DNS transaction authentication. Since the goal of DNS
Security extensions is to become part of the DNS protocol standard, Security extensions is to become part of the DNS protocol standard,
additional documents that seek to refine a portion of the security additional documents that seek to refine a portion of the security
extensions will be introduced as the specifications progress along extensions will be introduced as the specifications progress along
the IETF standards track. the IETF standards track.
There is a set of basic guidelines for each sub-category of documents There is a set of basic guidelines for each sub-category of documents
that explains what should be included, what should be considered a that explains what should be included, what should be considered a
protocol extension, and what should be considered an operational protocol extension, and what should be considered an operational
issue. Currently, there are at least two documents that fall under issue. Currently, there are at least two documents that fall under
operational security considerations that deal specifically with the operational security considerations that deal specifically with the
DNS security extensions: the first is RFC 2541 [6] which deals with DNS security extensions: the first is RFC 2541 [6] which deals with
the operational side of implementing the security extensions; the the operational side of implementing the security extensions; the
other is the CAIRN DNSSEC testbed Internet draft [CAIRN]. These other is the CAIRN DNSSEC testbed Internet draft [CAIRN]. These
documents should be considered part of the operational side of DNS, documents should be considered part of the operational side of DNS,
but will be addressed as a supplemental part of the DNS Security but will be addressed as a supplemental part of the DNS Security
roadmap. That is not to say that these two documents are not roadmap. That is not to say that these two documents are not
important to securing a DNS zone, but they do not directly address important to securing a DNS zone, but they do not directly address
the proposed DNS security extensions. Authors of documents that seek the proposed DNS security extensions. Authors of documents that seek
to address the operational concerns of DNS security should be aware to address the operational concerns of DNS security should be aware
of the structure of DNS Security documentation if they wish to of the structure of DNS Security documentation.
include their documents in the DNSEXT Working Group in addition to
the DNS Operations WG.
It is assumed the reader has some knowledge of the Domain Name System It is assumed the reader has some knowledge of the Domain Name System
[2] and the Domain Name System Security Extensions [1]. [2] and the Domain Name System Security Extensions.
2. Interrelationship of DNS Security Documents 2. Interrelationship of DNS Security Documents
The DNSSEC set of documents can be partitioned into five main groups 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 as depicted in Figure 1. All of these documents in turn are under
the larger umbrella group of DNS base protocol documents. It is the larger umbrella group of DNS base protocol documents. It is
possible that some documents fall into more than one of these possible that some documents fall into more than one of these
categories, such as RFC 2535, and should follow the guidelines for 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 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 limit the number of "uberdocuments" that try to be everything to
skipping to change at page 5, line 25 skipping to change at page 5, line 25
| |
+------------+ +-----------+ +-------------+ +------------+ +-----------+ +-------------+
| New | | DNSSEC | | New | | New | | DNSSEC | | New |
| Security |----------| protocol |----------| Security | | Security |----------| protocol |----------| Security |
| RRs | | | | Uses | | RRs | | | | Uses |
+------------+ | | +-------------+ +------------+ | | +-------------+
+-----------+ +-----------+
| |
| |
+----------------------+*********************** +----------------------+***********************
| | * | * *
| | * | * *
+------------+ +---------------+ +-*-*-*-*-*-*-*-*-+ +------------+ +---------------+ +-*-*-*-*-*-*-*-*-+
| DS | | | | Implementation | | DS | | | | Implementation |
| Algorithm | | Transactions | * Notes * | Algorithm | | Transactions | * Notes *
| Impl. | | | | | | Impl. | | | | |
+------------+ +---------------+ +-*-*-*-*-*-*-*-*-+ +------------+ +---------------+ +-*-*-*-*-*-*-*-*-+
DNSSEC Document Roadmap DNSSEC Document Roadmap
--------------------------------------------------------------------- ---------------------------------------------------------------------
The "DNSSEC protocol" document set refers to the document that makes The "DNSSEC protocol" document set refers to the document that makes
up the groundwork for adding security to the DNS protocol [1]and up the groundwork for adding security to the DNS protocol [1]and
updates to this document. RFC 2535 laid out the goals and updates to this document. RFC 2535 laid out the goals and
expectations of DNS Security and the new security-related Resource expectations of DNS Security and the new security-related Resource
Records KEY, SIG, DS [19] and NXT. Expanding from this document, Records KEY, SIG, DS, and NXT [23]. Expanding from this document,
related document groups include the implementation documents of related document groups include the implementation documents of
various digital signature algorithms with DNSSEC, and documents various digital signature algorithms with DNSSEC, and documents
further refining the transaction of messages. It is expected that further refining the transaction of messages. It is expected that
RFC 2535 will be obsoleted by one or more documents that refine the RFC 2535 will be obsoleted by one or more documents that refine the
set of security extensions and DNS security transactions [22], [23], set of security extensions [22], [23], [24]. Documents that seek to
[24]. Documents that seek to modify or clarify the base protocol modify or clarify the base protocol documents should state so clearly
documents should state so clearly in the introduction of the document in the introduction of the document (as well as proscribe to the IETF
(as well as proscribe to the IETF guidelines of RFC/Internet Draft guidelines of RFC/Internet Draft author guidelines). Also, the
author guidelines). Also, the portions of the specification to be portions of the specification to be modified should be synopsized in
modified should be synopsized in the new document for the benefit of the new document for the benefit of the reader. The "DNSSEC
the reader. The "DNSSEC protocol" set includes the documents [1], protocol" set includes the documents [1], [11], [12], [9], [14],
[11], [12], [9], [14], [15], [21], [20], [OPTIN], [16] and their [15], [21], [16], [OPTIN], [17] and their derivative documents.
derivative documents.
The "New Security RRs" set refers to the group of documents that seek The "New Security RRs" set refers to the group of documents that seek
to add additional Resource Records to the set of base DNS Record to add additional Resource Records to the set of base DNS Record
types. These new records can be related to securing the DNS protocol types. These new records can be related to securing the DNS protocol
[1], [8], or using DNS security for other purposes such as storing [1], [8], or using DNS security for other purposes such as storing
certificates [5]. certificates [5]. Another related document is [26]. While not
detailing a new RR type, it defines a flag bit in the existing KEY
RR. This flag bit does not affect the protocol interpretation of the
RR, only a possible operational difference. Therefore, this draft is
place here and not with the protocol document set.
The "DS Algorithm Impl" document set refers to the group of documents The "DS Algorithm Impl" document set refers to the group of documents
that describe how a specific digital signature algorithm is that describe how a specific digital signature algorithm is
implemented to fit the DNSSEC Resource Record format. Each one of implemented to fit the DNSSEC Resource Record format. Each one of
these documents deals with one specific digital signature algorithm. these documents deals with one specific digital signature algorithm.
Examples of this set include [4], [5], [25], [18][17] and [13]. Examples of this set include [4], [5], [25], [19][18] and [13].
The "Transactions" document set refers to the group of documents that The "Transactions" document set refers to the group of documents that
deal with the message transaction sequence of security-related DNS deal with the message transaction sequence of security-related DNS
operations. The contents and sequence for operations such as dynamic operations. The contents and sequence for operations such as dynamic
update [3], [11] and transaction signatures [10] are described in update [3], [11] and transaction signatures [10] are described in
this document category. Additional message transaction schemes to this document category. Additional message transaction schemes to
support DNSSEC operation would also fall under this group, including support DNSSEC operation would also fall under this group, including
secret key establishment [7], [RENEW], and verification. secret key establishment [7], [RENEW], and verification.
The final document set, "New Security Uses", refers to documents that The final document set, "New Security Uses", refers to documents that
skipping to change at page 7, line 4 skipping to change at page 7, line 7
include [SSH-DNS] and [IPSEC-DNS] which deals with storing SSH and include [SSH-DNS] and [IPSEC-DNS] which deals with storing SSH and
IPSec keying information the DNS using new records and utilizing IPSec keying information the DNS using new records and utilizing
DNSSEC to provide authentication and integrity checking. DNSSEC to provide authentication and integrity checking.
Lastly, there is a set of documents that should be classified as Lastly, there is a set of documents that should be classified as
"Implementation Notes". Because the DNS security extensions are "Implementation Notes". Because the DNS security extensions are
still in the developmental stage, there is an audience for documents still in the developmental stage, there is an audience for documents
that detail the transition and implementation of the security that detail the transition and implementation of the security
extensions. These have more to do with the practical side of DNS extensions. These have more to do with the practical side of DNS
operations, but can also point to places in the protocol operations, but can also point to places in the protocol
specifications that need improvement. Documents in this set may be specifications that need improvement. An example of this type is the
offspring of both the DNSEXT and/or DNSOP Working Groups. An example report on the CAIRN DNSSEC testbed [CAIRN] This document was
of this type is the report on the CAIRN DNSSEC testbed [CAIRN] This submitted through the DNSOP Working Group at the time of this
document was submitted through the DNSOP Working Group, however the writing, however the main concern of this document is the
main concern of this document is the implementation and limitations implementation and limitations of the DNS security extensions, hence
of the DNS security extensions, hence their interest to the DNS their interest to the DNS security community. The CAIRN draft deals
security community. The CAIRN draft deals with the implementation of with the implementation of a secure DNS. Authors of documents that
a secure DNS. Authors of documents that deal with the implementation deal with the implementation and operational side of the DNSSEC
and operational side of the DNSSEC specifications would be advised/ specifications would be advised/encouraged to submit their documents
encouraged to submit their documents to the DNSEXT Working Group as to any other relevant DNS related WG meeting in the problem space.
well.
3. Relationship of DNS Security Documents to other DNS Documents 3. Relationship of DNS Security Documents to other DNS Documents
The DNS security-related extensions should be considered a subset of The DNS security-related extensions should be considered a subset of
the DNS protocol. The DNS Security Working Group of the IETF the DNS protocol. Therefore, all DNS security-related documents
(DNSSEC) has been absorbed into the larger DNS Extensions Working should be seen as a subset of the main DNS architecture documents.
Group (DNSEXT). Therefore, all DNS security-related documents should It is a good idea for authors of future DNS security documents to be
be seen as a subset of the main DNS architecture documents. It is a familiar with the contents of these base protocol documents.
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 4. Recommended Content for new DNS Security Documents
Documents that seek to make additions or revisions to the DNS Documents that seek to make additions or revisions to the DNS
protocol to add security should follow common guidelines as to protocol to add security should follow common guidelines as to
minimum required content and structure. It is the purpose of this minimum required content and structure. It is the purpose of this
document roadmap to establish criteria for content that any new DNS document roadmap to establish criteria for content that any new DNS
security protocol specifications document should contain. These security protocol specifications document should contain. These
criteria should be interpreted as a minimum set of information criteria should be interpreted as a minimum set of information
required/needed in a document, any additional information regarding required/needed in a document, any additional information regarding
the specific extension should also be included in the document. the specific extension should also be included in the document.
These criteria are not officially part of the IETF guidelines These criteria are not officially part of the IETF guidelines
regarding RFC/Internet Drafts, but should be considered as guidance regarding RFC/Internet Drafts, but should be considered as guidance
to promote uniformity to Working Group documents. to promote uniformity to Working Group documents.
Since the addition of security to the DNS protocol is now considered Since the addition of security to the DNS protocol is now considered
a general extension to the DNS protocol, any guideline for the a general extension to the DNS protocol, any guideline for the
contents of a DNS Security document could be taken as a suggestion contents of a DNS Security document could be taken as a framework
for the contents of any DNS extension document. 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 4.1 Security Related Resource Records
Documents describing a new type of DNS Security Resource Record (RR) Documents describing a new type of DNS Security Resource Record (RR)
should contain information describing the structure and use of the 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 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 document, unless the set of new resource records are closely related
or a protocol extension requires the use of more than one new record or a protocol extension requires the use of more than one new record
type. Specifically, each document detailing a new security-related type. Specifically, each document detailing a new security-related
RR type should include the following information: RR type should include the following information:
skipping to change at page 10, line 43 skipping to change at page 10, line 45
operation and the required authority for that mechanism (i.e. operation and the required authority for that mechanism (i.e.
zone, host, or some other trusted authority such as a DNS zone, host, or some other trusted authority such as a DNS
administrator or certificate authority); administrator or certificate authority);
4.4 The Use of DNS Security Extensions with Other Protocols 4.4 The Use of DNS Security Extensions with Other Protocols
Because of the flexibility and ubiquity of the DNS, there may exist Because of the flexibility and ubiquity of the DNS, there may exist
other Internet protocols and applications that could make use of, or other Internet protocols and applications that could make use of, or
extend, the DNS security protocols. Examples of this type of extend, the DNS security protocols. Examples of this type of
document include the use of DNS to support IPSEC [IPSEC-DNS], SSH document include the use of DNS to support IPSEC [IPSEC-DNS], SSH
[SSH-DNS} the Public Key Infrastructure (PKI). It is beyond the [SSH-DNS] the Public Key Infrastructure (PKI). It is beyond the
scope of this roadmap to describe the contents of this class of scope of this roadmap to describe the contents of this class of
documents. However, if uses or extensions require the addition or documents. However, if uses or extensions require the addition or
modification of a DNS Resource Record type or DNS query/response modification of a DNS Resource Record type or DNS query/response
transactions, then the guidelines laid out in the previous sections transactions, then the guidelines laid out in the previous sections
of this document should be adhered to. of this document should be adhered to.
5. Security Considerations 5. Security Considerations
This document provides a roadmap and guidelines for writing DNS This document provides a roadmap and guidelines for writing DNS
Security related documents. The reader should follow all the Security related documents. This document does not discuss the
security procedures and guidelines described in the DNS Security aspects of the DNS security extensions. The reader should refer to
Extensions document [1]. the documents outlined here for the details of the services and
shortcomings of DNS security.
6. Acknowledgements 6. Acknowledgements
In addition to the RFCs mentioned in this document, there are also In addition to the RFCs mentioned in this document, there are also
numerous Internet drafts that fall in one or more of the categories numerous Internet drafts that fall in one or more of the categories
of DNS Security documents mentioned above. Depending on where (and of DNS Security documents mentioned above. Depending on where (and
if) these documents are on the IETF standards track, the reader may if) these documents are on the IETF standards track, the reader may
not be able to access these documents through the RFC repositories. not be able to access these documents through the RFC repositories.
All of these documents are "Work in Progress" and are subject to All of these documents are "Work in Progress" and are subject to
change; therefore a version number is not supplied for the current change; therefore a version number is not supplied for the current
skipping to change at page 13, line 5 skipping to change at page 13, line 5
o SSH-DNS: W. Griffin, J. Schlyter. "Using DNS to securely o SSH-DNS: W. Griffin, J. Schlyter. "Using DNS to securely
publish SSH key fingerprints" draft-ietf-secsh-dns-NN.txt publish SSH key fingerprints" draft-ietf-secsh-dns-NN.txt
o IPSEC-DNS: M. Richardson. "A method for storing IPsec keying o IPSEC-DNS: M. Richardson. "A method for storing IPsec keying
material in DNS". draft-richardson-ipsec-rr-NN.txt material in DNS". draft-richardson-ipsec-rr-NN.txt
o RENEW: Y. Kamite, M. Nakayama. "TKEY Secret Key Renewal Mode". o RENEW: Y. Kamite, M. Nakayama. "TKEY Secret Key Renewal Mode".
draft-ietf-dnsext-tkey-renewal-mode-NN.txt draft-ietf-dnsext-tkey-renewal-mode-NN.txt
References Normative References
[1] Eastlake, D., "Domain Name System Security Extensions", RFC [1] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999. 2535, March 1999.
[2] Mockapetris, P., "Domain names - implementation and [2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[3] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC [3] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
2137, April 1997. 2137, April 1997.
skipping to change at page 14, line 5 skipping to change at page 14, line 5
[13] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name [13] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
System (DNS)", RFC 3110, May 2001. System (DNS)", RFC 3110, May 2001.
[14] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, [14] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
December 2001. December 2001.
[15] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver [15] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
message size requirements", RFC 3226, December 2001. message size requirements", RFC 3226, December 2001.
[16] Austein, R. and D. Atkins, "Threat Analysis of the Domain Name [16] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
Record (RR)", RFC 3445, December 2002.
Informative References
[17] Austein, R. and D. Atkins, "Threat Analysis of the Domain Name
System (Work in Progress)", RFC XXXX. System (Work in Progress)", RFC XXXX.
[17] Eastlake, R., "Storage of Diffie-Hellman Keys in the Domain [18] Eastlake, R., "Storage of Diffie-Hellman Keys in the Domain
Name System (DNS) (Work in Progress)", RFC XXXX. Name System (DNS) (Work in Progress)", RFC XXXX.
[18] Eastlake, D. and R. Schroeppel, "Elliptic Curve KEYs in the DNS [19] Eastlake, D. and R. Schroeppel, "Elliptic Curve KEYs in the DNS
(Work in Progress)", RFC XXXX. (Work in Progress)", RFC XXXX.
[19] Gundmundsson, O., "Delegation Signer Record in Parent (Work in [20] Gundmundsson, O., "Delegation Signer Record in Parent (Work in
Progress)", RFC XXXX. Progress)", RFC XXXX.
[20] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
Record (Work in Progress)", RFC XXXX.
[21] Wellington, B., "Redefinition of the DNS AD bit (Work in [21] Wellington, B., "Redefinition of the DNS AD bit (Work in
Progress)", RFC XXXX. Progress)", RFC XXXX.
[22] Arends, R., Larson, M., Massey, D. and S. Rose, "DNS Security [22] Arends, R., Larson, M., Massey, D. and S. Rose, "DNS Security
Introduction and Requirements (Work in Progress)", RFC XXXX. Introduction and Requirements (Work in Progress)", RFC XXXX.
[23] Arends, R., Larson, M., Massey, D. and S. Rose, "DNS Security [23] Arends, R., Larson, M., Massey, D. and S. Rose, "Resource
Introduction and Requirements (Work in Progress)", RFC XXXX. Records for DNS Security Extensions (Work in Progress)", RFC
XXXX.
[24] Arends, R., Larson, M., Massey, D. and S. Rose, "DNS Security [24] Arends, R., Larson, M., Massey, D. and S. Rose, "Protocol
Introduction and Requirements (Work in Progress)", RFC XXXX. Modifications for the DNS Security Extensions (Work in
Progress)", RFC XXXX.
[25] Kwan, S., Garg, P., Gilroy, J. and L. Esibov, "GSS Algorithm [25] Kwan, S., Garg, P., Gilroy, J. and L. Esibov, "GSS Algorithm
for TSIG (Work in Progress)", RFC XXXX. 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 Author's Address
Scott Rose Scott Rose
National Institute for Standards and Technology National Institute for Standards and Technology
100 Bureau Drive 100 Bureau Drive
Gaithersburg, MD 20899-3460 Gaithersburg, MD 20899-3460
USA USA
EMail: scott.rose@nist.gov EMail: scott.rose@nist.gov
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 28 change blocks. 
69 lines changed or deleted 78 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/