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/ |