draft-ietf-dnsext-dnssec-rsasha256-11.txt   draft-ietf-dnsext-dnssec-rsasha256-12.txt 
DNS Extensions working group J. Jansen DNS Extensions working group J. Jansen
Internet-Draft NLnet Labs Internet-Draft NLnet Labs
Intended status: Standards Track February 27, 2009 Intended status: Standards Track March 23, 2009
Expires: August 31, 2009 Expires: September 24, 2009
Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records
for DNSSEC for DNSSEC
draft-ietf-dnsext-dnssec-rsasha256-11 draft-ietf-dnsext-dnssec-rsasha256-12
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
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 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 August 31, 2009. This Internet-Draft will expire on September 24, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 5, line 29 skipping to change at page 5, line 29
Apart from the restrictions in section 2, this document will not Apart from the restrictions in section 2, this document will not
specify what size of keys to use. That is an operational issue and specify what size of keys to use. That is an operational issue and
depends largely on the environment and intended use. A good starting depends largely on the environment and intended use. A good starting
point for more information would be NIST SP 800-57 [NIST800-57]. point for more information would be NIST SP 800-57 [NIST800-57].
4.2. Signature Sizes 4.2. Signature Sizes
In this family of signing algorithms, the size of signatures is In this family of signing algorithms, the size of signatures is
related to the size of the key, and not the hashing algorithm used in related to the size of the key, and not the hashing algorithm used in
the signing process. Therefore, RRSIG resource records produced with the signing process. Therefore, RRSIG resource records produced with
RSA/SHA256 or RSA/SHA512 will have the same size as those produced RSA/SHA-256 or RSA/SHA-512 will have the same size as those produced
with RSA/SHA1, if the keys have the same length. with RSA/SHA-1, if the keys have the same length.
5. Implementation Considerations 5. Implementation Considerations
5.1. Support for SHA-2 signatures 5.1. Support for SHA-2 signatures
DNSSEC aware implementations SHOULD be able to support RRSIG and DNSSEC aware implementations SHOULD be able to support RRSIG and
DNSKEY resource records created with the RSA/SHA-2 algorithms as DNSKEY resource records created with the RSA/SHA-2 algorithms as
defined in this document. defined in this document.
5.2. Support for NSEC3 Denial of Existence 5.2. Support for NSEC3 Denial of Existence
RFC5155 [RFC5155] defines new algorithm identifiers for existing RFC5155 [RFC5155] defines new algorithm identifiers for existing
signing algorithms, to indicate that zones signed with these signing algorithms, to indicate that zones signed with these
algorithm identifiers use NSEC3 instead of NSEC records to provide algorithm identifiers can use NSEC3 as well as NSEC records to
denial of existence. That mechanism was chosen to protect provide denial of existence. That mechanism was chosen to protect
implementations predating RFC5155 from encountering resource records implementations predating RFC5155 from encountering resource records
they could not know about. This document does not define such they could not know about. This document does not define such
algorithm aliases, and support for NSEC3 denial of existence is algorithm aliases, and support for NSEC3 denial of existence is
implicitly signaled with support for one of the algorithms defined in implicitly signaled with support for one of the algorithms defined in
this document. this document.
5.2.1. NSEC3 in Authoritative servers 5.2.1. NSEC3 in Authoritative servers
An authoritative server that does not implement NSEC3 MAY still serve An authoritative server that does not implement NSEC3 MAY still serve
zones that use RSA/SHA2 with NSEC denial of existence. zones that use RSA/SHA-2 with NSEC denial of existence.
5.2.2. NSEC3 in Validators 5.2.2. NSEC3 in Validators
A DNSSEC validator that implements RSA/SHA2 MUST be able to handle A DNSSEC validator that implements RSA/SHA-2 MUST be able to handle
both NSEC and NSEC3 [RFC5155] negative answers. If this is not the both NSEC and NSEC3 [RFC5155] negative answers. If this is not the
case, the validator MUST treat a zone signed with RSA/SHA256 or RSA/ case, the validator MUST treat a zone signed with RSA/SHA-256 or RSA/
SHA512 as signed with an unknown algorithm, and thus as insecure. SHA-512 as signed with an unknown algorithm, and thus as insecure.
6. IANA Considerations 6. IANA Considerations
This document updates the IANA registry "DNS SECURITY ALGORITHM This document updates the IANA registry "DNS SECURITY ALGORITHM
NUMBERS -- per [RFC4035] " NUMBERS -- per [RFC4035] "
(http://www.iana.org/assignments/dns-sec-alg-numbers). The following (http://www.iana.org/assignments/dns-sec-alg-numbers). The following
entries are added to the registry: entries are added to the registry:
Zone Zone Trans.
Value Algorithm Mnemonic Signing References Value Description Mnemonic Signing Sec. References
{TBA1} RSA/SHA-256 RSASHA256 y {this memo} {TBA1} RSA/SHA-256 RSASHA256 y * {this memo}
{TBA2} RSA/SHA-512 RSASHA512 y {this memo} {TBA2} RSA/SHA-512 RSASHA512 y * {this memo}
* There has been no determination of standardization of the use of this
algorithm with Transaction Security.
7. Security Considerations 7. Security Considerations
7.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource Records 7.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource Records
Users of DNSSEC are encouraged to deploy SHA-2 as soon as software Users of DNSSEC are encouraged to deploy SHA-2 as soon as software
implementations allow for it. SHA-2 is widely believed to be more implementations allow for it. SHA-2 is widely believed to be more
resilient to attack than SHA-1, and confidence in SHA-1's strength is resilient to attack than SHA-1, and confidence in SHA-1's strength is
being eroded by recently-announced attacks. Regardless of whether or being eroded by recently-announced attacks. Regardless of whether or
not the attacks on SHA-1 will affect DNSSEC, it is believed (at the not the attacks on SHA-1 will affect DNSSEC, it is believed (at the
 End of changes. 9 change blocks. 
16 lines changed or deleted 19 lines changed or added

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