--- 1/draft-ietf-dnsext-ds-sha256-01.txt 2006-02-04 17:14:30.000000000 +0100 +++ 2/draft-ietf-dnsext-ds-sha256-02.txt 2006-02-04 17:14:30.000000000 +0100 @@ -1,17 +1,17 @@ Network Working Group W. Hardaker Internet-Draft Sparta -Expires: June 2, 2006 November 29, 2005 +Expires: June 12, 2006 December 9, 2005 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) - draft-ietf-dnsext-ds-sha256-01.txt + draft-ietf-dnsext-ds-sha256-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -22,21 +22,21 @@ 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. - This Internet-Draft will expire on June 2, 2006. + This Internet-Draft will expire on June 12, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies how to use the SHA-256 digest type in DNS Delegation Signer (DS) Resource Records (RRs). DS records, when stored in a parent zone, point to key signing DNSKEY key(s) in a @@ -57,23 +57,25 @@ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 1. Introduction The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent zones to distribute a cryptographic digest of a child's Key Signing - Key (KSK) DNSKEY RR. This DS RR is signed using the parent zone's - private half of it's DNSKEY and the signature is published in a RRSIG - record. + Key (KSK) DNSKEY RR. The DS RRset is signed by at least one of the + parent zone's private zone data signing keys for each algorithm in + use by the parent. Each signature is published in an RRSIG resource + record, owned by the same domain as the DS RRset and with a type + covered of DS. 2. Implementing the SHA-256 algorithm for DS record support This document specifies that the digest type code [XXX: To be assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256] for use within DS records. The results of the digest algorithm MUST NOT be truncated and the entire 32 byte digest result is to be published in the DS record. 2.1. DS record field values @@ -92,36 +94,36 @@ where DNSKEY RDATA is defined by [RFC4034] as: DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key The Key Tag field and Algorithm fields remain unchanged by this document and are specified in the [RFC4034] specification. 2.2. DS Record with SHA-256 Wire Format - The resulting packet format for the resulting DS record will be [XXX: - IANA assignment should replace the 2 below]: + The resulting on-the-wire format for the resulting DS record will be + [XXX: IANA assignment should replace the 2 below]: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Tag | Algorithm | DigestType=2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Digest (length for SHA-256 is 32 bytes) / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 2.3. Example DS Record Using SHA-256 - The following is an example DSKEY and matching DS record. This + The following is an example DNSKEY and matching DS record. This DNSKEY record comes from the example DNSKEY/DS records found in section 5.4 of [RFC4034]. The DNSKEY record:: dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz fwJr1AYtsmx3TGkJaNXVbfi/ 2pHm822aJ5iI9BMzNXxeYCmZ DRD99WYwYqUSdjMmmAphXdvx egXd/M5+X7OrzKBaMbCVdFLU @@ -136,42 +138,43 @@ dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C CEB1E3E0614B93C4F9E99B83 83F6A1E4469DA50A ) 3. Implementation Requirements Implementations MUST support the use of the SHA-256 algorithm in DS RRs. - Validator implementations MUST be able to prefer DS records - containing SHA-256 digests over those containing SHA-1 digests. This - behavior SHOULD by the default. Validator implementations MAY - provide configuration settings that allow network operators to - specify preference policy when validating multiple DS records - containing different digest types. + Validator implementations MUST, by default, ignore DS RRs containing + SHA-1 digests if DS RRs with SHA-256 digests are present in the DS + RRset. This behavior SHOULD be the default. Validator + implementations MAY provide configuration settings that allow network + operators to specify preference policy when validating multiple DS + records containing different digest types. 4. Deployment Considerations If a validator does not support the SHA-256 digest type and no other DS RR exists in a zone's DS RRset with a supported digest type, then the validator has no supported authentication path leading from the parent to the child. The resolver should treat this case as it would the case of an authenticated NSEC RRset proving that no DS RRset exists, as described in [RFC4035], section 5.2. - Because zone administrators can not control the deployment support of - SHA-256 in deployed validators that may referencing any given zone, - deployments should consider publishing both SHA-1 and SHA-256 based - DS records for a while. Whether to publish both digest types - together and for how long is a policy decision that extends beyond - the scope of this document. + Because zone administrators can not control the deployment speed of + support for SHA-256 in validators that may be referencing any of + their zones, zone operators should consider deploying both SHA-1 and + SHA-256 based DS records. This should be done for every DNSKEY for + which DS records are being generated. Whether to make use of both + digest types and for how long is a policy decision that extends + beyond the scope of this document. 5. IANA Considerations The Digest Type to be used for supporting SHA-256 within DS records needs to be assigned by IANA. This document requests that the Digest Type value of 2 be assigned to the SHA-256 digest algorithm. At the time of this writing, the current digest types assigned for use in DS records are as follows: @@ -198,23 +201,23 @@ Likewise, it is also beyond the scope of this document to specify whether or for how long SHA-1 based DS records should be simultaneously published alongside SHA-256 based DS records. 7. Acknowledgments This document is a minor extension to the existing DNSSEC documents and those authors are gratefully appreciated for the hard work that went into the base documents. - The following people contributed to valuable technical content of - this document: Roy Arends, Olafur Gudmundsson, Olaf M. Kolkman, Scott - Rose, Sam Weiler. + The following people contributed to portions of this document in some + fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Olaf M. + Kolkman, Edward Lewis, Scott Rose, Sam Weiler. 8. References 8.1. Normative References [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.