draft-ietf-dnsext-ds-sha256-01.txt   draft-ietf-dnsext-ds-sha256-02.txt 
Network Working Group W. Hardaker Network Working Group W. Hardaker
Internet-Draft Sparta 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) 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 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 June 2, 2006. This Internet-Draft will expire on June 12, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document specifies how to use the SHA-256 digest type in DNS This document specifies how to use the SHA-256 digest type in DNS
Delegation Signer (DS) Resource Records (RRs). DS records, when Delegation Signer (DS) Resource Records (RRs). DS records, when
stored in a parent zone, point to key signing DNSKEY key(s) in a stored in a parent zone, point to key signing DNSKEY key(s) in a
skipping to change at page 3, line 9 skipping to change at page 3, line 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 8
1. Introduction 1. Introduction
The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in 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. The DS RRset is signed by at least one of the
private half of it's DNSKEY and the signature is published in a RRSIG parent zone's private zone data signing keys for each algorithm in
record. 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 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 3, line 44 skipping to change at page 3, line 46
where DNSKEY RDATA is defined by [RFC4034] as: where DNSKEY RDATA is defined by [RFC4034] as:
DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key
The Key Tag field and Algorithm fields remain unchanged by this The Key Tag field and Algorithm fields remain unchanged by this
document and are specified in the [RFC4034] specification. document and are specified in the [RFC4034] specification.
2.2. DS Record with SHA-256 Wire Format 2.2. DS Record with SHA-256 Wire Format
The resulting packet format for the resulting DS record will be [XXX: The resulting on-the-wire format for the resulting DS record will be
IANA assignment should replace the 2 below]: [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 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 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 DNSKEY record comes from the example DNSKEY/DS records found in
section 5.4 of [RFC4034]. section 5.4 of [RFC4034].
The DNSKEY record:: The DNSKEY record::
dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
fwJr1AYtsmx3TGkJaNXVbfi/ fwJr1AYtsmx3TGkJaNXVbfi/
2pHm822aJ5iI9BMzNXxeYCmZ 2pHm822aJ5iI9BMzNXxeYCmZ
DRD99WYwYqUSdjMmmAphXdvx DRD99WYwYqUSdjMmmAphXdvx
egXd/M5+X7OrzKBaMbCVdFLU egXd/M5+X7OrzKBaMbCVdFLU
skipping to change at page 4, line 46 skipping to change at page 4, line 46
dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C
CEB1E3E0614B93C4F9E99B83 CEB1E3E0614B93C4F9E99B83
83F6A1E4469DA50A ) 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.
Validator implementations MUST be able to prefer DS records Validator implementations MUST, by default, ignore DS RRs containing
containing SHA-256 digests over those containing SHA-1 digests. This SHA-1 digests if DS RRs with SHA-256 digests are present in the DS
behavior SHOULD by the default. Validator implementations MAY RRset. This behavior SHOULD be the default. Validator
provide configuration settings that allow network operators to implementations MAY provide configuration settings that allow network
specify preference policy when validating multiple DS records operators to specify preference policy when validating multiple DS
containing different digest types. records containing different digest types.
4. Deployment Considerations 4. Deployment Considerations
If a validator does not support the SHA-256 digest type and no other 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 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 the validator has no supported authentication path leading from the
parent to the child. The resolver should treat this case as it would 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 the case of an authenticated NSEC RRset proving that no DS RRset
exists, as described in [RFC4035], section 5.2. exists, as described in [RFC4035], section 5.2.
Because zone administrators can not control the deployment support of Because zone administrators can not control the deployment speed of
SHA-256 in deployed validators that may referencing any given zone, support for SHA-256 in validators that may be referencing any of
deployments should consider publishing both SHA-1 and SHA-256 based their zones, zone operators should consider deploying both SHA-1 and
DS records for a while. Whether to publish both digest types SHA-256 based DS records. This should be done for every DNSKEY for
together and for how long is a policy decision that extends beyond which DS records are being generated. Whether to make use of both
the scope of this document. digest types 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 At the time of this writing, the current digest types assigned for
use in DS records are as follows: use in DS records are as follows:
skipping to change at page 6, line 13 skipping to change at page 6, line 15
Likewise, it is also beyond the scope of this document to specify Likewise, it is also beyond the scope of this document to specify
whether or for how long SHA-1 based DS records should be whether or for how long SHA-1 based DS records should be
simultaneously published alongside SHA-256 based DS records. 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 The following people contributed to portions of this document in some
this document: Roy Arends, Olafur Gudmundsson, Olaf M. Kolkman, Scott fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Olaf M.
Rose, Sam Weiler. Kolkman, Edward Lewis, 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.
 End of changes. 9 change blocks. 
24 lines changed or deleted 27 lines changed or added

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