draft-ietf-dnsext-ds-sha256-00.txt   draft-ietf-dnsext-ds-sha256-01.txt 
Network Working Group W. Hardaker Network Working Group W. Hardaker
Internet-Draft Sparta Internet-Draft Sparta
Expires: May 14, 2006 November 10, 2005 Expires: June 2, 2006 November 29, 2005
Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
draft-ietf-dnsext-ds-sha256-00.txt draft-ietf-dnsext-ds-sha256-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://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 May 14, 2006. This Internet-Draft will expire on June 2, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document defines the use of the SHA-256 digest type for creating This document specifies how to use the SHA-256 digest type in DNS
digests of DNSKEY Resource Records (RRs). These digests can then be Delegation Signer (DS) Resource Records (RRs). DS records, when
published in Delegation Signer (DS) resource records (RRs) by a stored in a parent zone, point to key signing DNSKEY key(s) in a
parent zone. child zone.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Implementing the SHA-256 algorithm for DS record support . . . 3 2. Implementing the SHA-256 algorithm for DS record support . . . 3
2.1. DS record field values . . . . . . . . . . . . . . . . . . 3 2.1. DS record field values . . . . . . . . . . . . . . . . . . 3
2.2. DS Record with SHA-256 Wire Format . . . . . . . . . . . . 3 2.2. DS Record with SHA-256 Wire Format . . . . . . . . . . . . 3
2.3. Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4
3. Implementation Requirements . . . . . . . . . . . . . . . . . . 4 3. Implementation Requirements . . . . . . . . . . . . . . . . . . 4
4. Deployment Requirements . . . . . . . . . . . . . . . . . . . . 4 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 7
1. Introduction 1. Introduction
The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published by parent The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent
zones to distribute a cryptographic digest of a child's Key Signing 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 Key (KSK) DNSKEY RR. This DS RR is signed using the parent zone's
private half of it's DNSKEY and is published in a RRSIG record. private half of it's DNSKEY and the signature is published in a RRSIG
record.
2. Implementing the SHA-256 algorithm for DS record support 2. Implementing the SHA-256 algorithm for DS record support
This document specifies that the digest type code [XXX: To be 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 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 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 be truncated and the entire 32 byte digest result is to be published
in the DS record. in the DS record.
2.1. DS record field values 2.1. DS record field values
skipping to change at page 4, line 15 skipping to change at page 4, line 15
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 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 | | Key Tag | Algorithm | DigestType=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ / / /
/ Digest (length for SHA-256 is 32 bytes) / / 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
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
Uh6DhweJBjEVv5f2wwjM9Xzc
nOf+EPbtG9DMBmADjFDc2w/r
ljwvFw==
) ; key id = 60485
The resulting DS record covering the above DNSKEY record using a SHA-
256 digest: [RFC Editor: please replace XXX with the assigned digest
type (likely 2):]
dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C
CEB1E3E0614B93C4F9E99B83
83F6A1E4469DA50A )
3. Implementation Requirements 3. Implementation Requirements
Implementations MUST support the use of the SHA-256 algorithm in DS Implementations MUST support the use of the SHA-256 algorithm in DS
RRs. RRs.
Implementations that support SHA-256 MUST prefer DS records with SHA- Validator implementations MUST be able to prefer DS records
256 (digest type number [XXX: RFC to be assigned by IANA; likely 2]) containing SHA-256 digests over those containing SHA-1 digests. This
digests over DS records with SHA-1 (digest type number 1) digests. 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.
4. Deployment Requirements 4. Deployment Considerations
Deployments SHOULD publish both SHA-1 and SHA-256 based DS records If a validator does not support the SHA-256 digest type and no other
for 2 years from the publication date of this RFC (XXX: RFC Editor: DS RR exists in a zone's DS RRset with a supported digest type, then
Please insert the calculated date here). 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.
5. IANA Considerations 5. IANA Considerations
The Digest Type to be used for supporting SHA-256 within DS records 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 needs to be assigned by IANA. This document requests that the Digest
Type value of 2 be assigned to the SHA-256 digest algorithm. 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:
VALUE Digest Type Status
0 Reserved -
1 SHA-1 MANDATORY
2 SHA-256 MANDATORY
3-255 Unassigned -
6. Security Considerations 6. Security Considerations
Because of the weaknesses recently discovered within the SHA-1 Because of the weaknesses recently discovered within the SHA-1
algorithm, users of DNSSEC are encouraged to deploy the use of SHA- algorithm, users of DNSSEC are encouraged to deploy the use of SHA-
256 as soon as software implementations in use allow for it. 256 as soon as the software implementations in use allow for it.
At the time of this publication, the SHA-256 algorithm is considered At the time of this publication, the SHA-256 digest algorithm is
sufficiently strong for the immediate future. It is considered also considered sufficiently strong for the immediate future. It is also
considered sufficient for use in DNSSEC DS RRs for the immediate considered sufficient for use in DNSSEC DS RRs for the immediate
future. However, future published attacks may, of course, weaken the future. However, future published attacks may, of course, weaken the
usability of this algorithm within the DS RRs. usability of this algorithm within the DS RRs. It is beyond the
scope of this document to speculate extensively on the cryptographic
strength of the SHA-256 digest algorithm.
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 7. Acknowledgments
This document is a minor extension to the existing DNSSEC documents This document is a minor extension to the existing DNSSEC documents
and those authors are gratefully appreciated for the hard work that and those authors are gratefully appreciated for the hard work that
went into the base documents. 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.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
skipping to change at page 5, line 32 skipping to change at page 7, line 5
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[SHA256] National Institute of Standards and Technology, "Secure [SHA256] National Institute of Standards and Technology, "Secure
Hash Algorithm. NIST FIPS 180-2", August 2002. Hash Algorithm. NIST FIPS 180-2", August 2002.
8.2. Informative References 8.2. Informative References
Appendix A. Example
TBD
Author's Address Author's Address
Wes Hardaker Wes Hardaker
Sparta Sparta
P.O. Box 382 P.O. Box 382
Davis 95617 Davis 95617
US US
Email: hardaker@tislabs.com Email: hardaker@tislabs.com
 End of changes. 18 change blocks. 
34 lines changed or deleted 89 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/