draft-ietf-dnsext-ds-sha256-04.txt   draft-ietf-dnsext-ds-sha256-05.txt 
Network Working Group W. Hardaker Network Working Group W. Hardaker
Internet-Draft Sparta Internet-Draft Sparta
Expires: July 17, 2006 January 13, 2006 Expires: August 25, 2006 February 21, 2006
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-04.txt draft-ietf-dnsext-ds-sha256-05.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 July 17, 2006. This Internet-Draft will expire on August 25, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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 2, line 19 skipping to change at page 2, line 19
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 2.3. Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4
3. Implementation Requirements . . . . . . . . . . . . . . . . . . 4 3. Implementation Requirements . . . . . . . . . . . . . . . . . . 4
4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6.1. Potential Digest Type Downgrade Attacks . . . . . . . . . . 5 6.1. Potential Digest Type Downgrade Attacks . . . . . . . . . . 5
6.2. SHA-1 vs SHA-256 Considerations for DS Records . . . . . . 6 6.2. SHA-1 vs SHA-256 Considerations for DS Records . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 9
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. The DS RRset is signed by at least one of the 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 parent zone's private zone data signing keys for each algorithm in
use by the parent. Each signature is published in an RRSIG resource 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 record, owned by the same domain as the DS RRset and with a type
covered of DS. covered of DS.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
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]
use within DS records. The results of the digest algorithm MUST NOT [SHA256CODE] for use within DS records. The results of the digest
be truncated and the entire 32 byte digest result is to be published algorithm MUST NOT be truncated and the entire 32 byte digest result
in the DS record. is to be published in the DS record.
2.1. DS record field values 2.1. DS record field values
Using the SHA-256 digest algorithm within a DS record will make use Using the SHA-256 digest algorithm within a DS record will make use
of the following DS-record fields: of the following DS-record fields:
Digest type: [XXX: To be assigned by IANA; likely 2] Digest type: [XXX: To be assigned by IANA; likely 2]
Digest: A SHA-256 bit digest value calculated by using the following Digest: A SHA-256 bit digest value calculated by using the following
formula ("|" denotes concatenation). The resulting value is not formula ("|" denotes concatenation). The resulting value is not
skipping to change at page 5, line 19 skipping to change at page 5, line 19
Because zone administrators can not control the deployment speed of Because zone administrators can not control the deployment speed of
support for SHA-256 in validators that may be referencing any of support for SHA-256 in validators that may be referencing any of
their zones, zone operators should consider deploying both SHA-1 and their zones, zone operators should consider deploying both SHA-1 and
SHA-256 based DS records. This should be done for every DNSKEY for 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 which DS records are being generated. Whether to make use of both
digest types and for how long is a policy decision that extends digest types and for how long is a policy decision that extends
beyond the scope of this document. beyond the scope of this document.
5. IANA Considerations 5. IANA Considerations
Only one IANA action is required by this document:
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:
VALUE Digest Type Status VALUE Digest Type Status
0 Reserved - 0 Reserved -
1 SHA-1 MANDATORY 1 SHA-1 MANDATORY
skipping to change at page 6, line 17 skipping to change at page 6, line 20
o The DS record with the SHA-256 digest fails to match the digest o The DS record with the SHA-256 digest fails to match the digest
computed using the child zone's DNSKEY. computed using the child zone's DNSKEY.
Then if the validator accepts the above situation as secure then this Then if the validator accepts the above situation as secure then this
can be used as a downgrade attack since the stronger SHA-256 digest can be used as a downgrade attack since the stronger SHA-256 digest
is ignored. is ignored.
6.2. SHA-1 vs SHA-256 Considerations for DS Records 6.2. SHA-1 vs SHA-256 Considerations for DS Records
Because of the weaknesses recently discovered within the SHA-1 Users of DNSSEC are encouraged to deploy SHA-256 as soon as software
algorithm, users of DNSSEC are encouraged to deploy the use of SHA- implementations allow for it. SHA-256 is widely believed to be more
256 as soon as the software implementations in use allow for it. resilient to attack than SHA-1, and confidence in SHA-1's strength is
being eroded by recently-announced attacks. Regardless of whether or
not the attacks on SHA-1 will affect DNSSEC, it is believed (at the
time of this writing) that SHA-256 is the better choice for use in DS
records.
At the time of this publication, the SHA-256 digest algorithm is At the time of this publication, the SHA-256 digest algorithm is
considered sufficiently strong for the immediate future. It is 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 weaken the usability future. However, future published attacks may weaken the usability
of this algorithm within the DS RRs. It is beyond the scope of this of this algorithm within the DS RRs. It is beyond the scope of this
document to speculate extensively on the cryptographic strength of document to speculate extensively on the cryptographic strength of
the SHA-256 digest algorithm. the SHA-256 digest algorithm.
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 portions of this document in some The following people contributed to portions of this document in some
fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Olaf M. fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman,
Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam Weiler. Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam
Weiler.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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",
RFC 4034, March 2005. RFC 4034, March 2005.
[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
[SHA256CODE] [SHA256CODE]
Motorola Labs, "US Secure Hash Algorithms (SHA)", Eastlake, D., "US Secure Hash Algorithms (SHA)",
June 2005. June 2005.
Author's Address Author's Address
Wes Hardaker Wes Hardaker
Sparta Sparta
P.O. Box 382 P.O. Box 382
Davis 95617 Davis, CA 95617
US US
Email: hardaker@tislabs.com Email: hardaker@tislabs.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
 End of changes. 12 change blocks. 
16 lines changed or deleted 30 lines changed or added

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