draft-ietf-dnsext-dnssec-rsasha256-09.txt   draft-ietf-dnsext-dnssec-rsasha256-10.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 December 04, 2008 Intended status: Standards Track January 08, 2009
Expires: June 7, 2009 Expires: July 12, 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-09 draft-ietf-dnsext-dnssec-rsasha256-10
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 7, 2009. This Internet-Draft will expire on July 12, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
This document describes how to produce RSA/SHA-256 and RSA/SHA-512 This document describes how to produce RSA/SHA-256 and RSA/SHA-512
DNSKEY and RRSIG resource records for use in the Domain Name System DNSKEY and RRSIG resource records for use in the Domain Name System
Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3 2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3
2.1. RSA/SHA-256 DNSKEY Resource Records . . . . . . . . . . . . 3 2.1. RSA/SHA-256 DNSKEY Resource Records . . . . . . . . . . . . 3
2.2. RSA/SHA-512 DNSKEY Resource Records . . . . . . . . . . . . 4 2.2. RSA/SHA-512 DNSKEY Resource Records . . . . . . . . . . . . 3
3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . . 4 3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . . 4
3.1. RSA/SHA-256 RRSIG Resource Records . . . . . . . . . . . . 4 3.1. RSA/SHA-256 RRSIG Resource Records . . . . . . . . . . . . 4
3.2. RSA/SHA-512 RRSIG Resource Records . . . . . . . . . . . . 5 3.2. RSA/SHA-512 RRSIG Resource Records . . . . . . . . . . . . 4
4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 5 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 5
4.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 5
5. Implementation Considerations . . . . . . . . . . . . . . . . . 5 5. Implementation Considerations . . . . . . . . . . . . . . . . . 5
5.1. Support for SHA-2 signatures . . . . . . . . . . . . . . . 5 5.1. Support for SHA-2 signatures . . . . . . . . . . . . . . . 5
5.2. Support for NSEC3 Denial of Existence . . . . . . . . . . . 5
5.2.1. NSEC3 in Authoritative servers . . . . . . . . . . . . 5
5.2.2. NSEC3 in Validators . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource 7.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource
Records . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Records . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.2. Signature Type Downgrade Attacks . . . . . . . . . . . . . 6 7.2. Signature Type Downgrade Attacks . . . . . . . . . . . . . 6
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
1. Introduction 1. Introduction
The Domain Name System (DNS) is the global hierarchical distributed The Domain Name System (DNS) is the global hierarchical distributed
database for Internet Naming. The DNS has been extended to use database for Internet Naming. The DNS has been extended to use
cryptographic keys and digital signatures for the verification of the cryptographic keys and digital signatures for the verification of the
authenticity and integrity of its data. RFC 4033 [RFC4033], RFC 4034 authenticity and integrity of its data. RFC 4033 [RFC4033], RFC 4034
[RFC4034], and RFC 4035 [RFC4035] describe these DNS Security [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security
Extensions, called DNSSEC. Extensions, called DNSSEC.
skipping to change at page 3, line 43 skipping to change at page 3, line 43
2. DNSKEY Resource Records 2. DNSKEY Resource Records
The format of the DNSKEY RR can be found in RFC 4034 [RFC4034]. RFC The format of the DNSKEY RR can be found in RFC 4034 [RFC4034]. RFC
3110 [RFC3110] describes the use of RSA/SHA-1 for DNSSEC signatures. 3110 [RFC3110] describes the use of RSA/SHA-1 for DNSSEC signatures.
2.1. RSA/SHA-256 DNSKEY Resource Records 2.1. RSA/SHA-256 DNSKEY Resource Records
RSA public keys for use with RSA/SHA-256 are stored in DNSKEY RSA public keys for use with RSA/SHA-256 are stored in DNSKEY
resource records (RRs) with the algorithm number {TBA1}. resource records (RRs) with the algorithm number {TBA1}.
For use with NSEC3 [RFC5155], the algorithm number for RSA/SHA-256
will be {TBA2}. The use of a different algorithm number to
differentiate between the use of NSEC and NSEC3 is in keeping with
the approach adopted in RFC5155.
For interoperability, as in RFC 3110 [RFC3110], the key size of RSA/ For interoperability, as in RFC 3110 [RFC3110], the key size of RSA/
SHA-256 keys MUST NOT be less than 512 bits, and MUST NOT be more SHA-256 keys MUST NOT be less than 512 bits, and MUST NOT be more
than 4096 bits. than 4096 bits.
2.2. RSA/SHA-512 DNSKEY Resource Records 2.2. RSA/SHA-512 DNSKEY Resource Records
RSA public keys for use with RSA/SHA-512 are stored in DNSKEY RSA public keys for use with RSA/SHA-512 are stored in DNSKEY
resource records (RRs) with the algorithm number {TBA3}. resource records (RRs) with the algorithm number {TBA2}.
For use with NSEC3, the algorithm number for RSA/SHA-512 will be
{TBA4}. The use of a different algorithm number to differentiate
between the use of NSEC and NSEC3 is in keeping with the approach
adopted in RFC5155.
The key size of RSA/SHA-512 keys MUST NOT be less than 1024 bits, and The key size of RSA/SHA-512 keys MUST NOT be less than 1024 bits, and
MUST NOT be more than 4096 bits. MUST NOT be more than 4096 bits.
3. RRSIG Resource Records 3. RRSIG Resource Records
The value of the signature field in the RRSIG RR follows the RSASSA- The value of the signature field in the RRSIG RR follows the RSASSA-
PKCS1-v1_5 signature scheme, and is calculated as follows. The PKCS1-v1_5 signature scheme, and is calculated as follows. The
values for the RDATA fields that precede the signature data are values for the RDATA fields that precede the signature data are
specified in RFC 4034 [RFC4034]. specified in RFC 4034 [RFC4034].
skipping to change at page 4, line 51 skipping to change at page 4, line 41
The "prefix" is intended to make the use of standard cryptographic The "prefix" is intended to make the use of standard cryptographic
libraries easier. These specifications are taken directly from the libraries easier. These specifications are taken directly from the
specifications of RSASSA-PKCS1-v1_5 in PKCS #1 v2.1 section 8.2 specifications of RSASSA-PKCS1-v1_5 in PKCS #1 v2.1 section 8.2
[RFC3447], and EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 section 9.2 [RFC3447], and EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 section 9.2
[RFC3447]. The prefixes for the different algorithms are specified [RFC3447]. The prefixes for the different algorithms are specified
below. below.
3.1. RSA/SHA-256 RRSIG Resource Records 3.1. RSA/SHA-256 RRSIG Resource Records
RSA/SHA-256 signatures are stored in the DNS using RRSIG resource RSA/SHA-256 signatures are stored in the DNS using RRSIG resource
records (RRs) with algorithm number {TBA1} for use with NSEC, or records (RRs) with algorithm number {TBA1}.
{TBA2} for use with NSEC3.
The prefix is the ASN.1 DER SHA-256 algorithm designator prefix as The prefix is the ASN.1 DER SHA-256 algorithm designator prefix as
specified in PKCS #1 v2.1 [RFC3447]: specified in PKCS #1 v2.1 [RFC3447]:
hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
3.2. RSA/SHA-512 RRSIG Resource Records 3.2. RSA/SHA-512 RRSIG Resource Records
RSA/SHA-512 signatures are stored in the DNS using RRSIG resource RSA/SHA-512 signatures are stored in the DNS using RRSIG resource
records (RRs) with algorithm number {TBA3} for use with NSEC, or records (RRs) with algorithm number {TBA2}.
{TBA4} for use with NSEC3.
The prefix is the ASN.1 DER SHA-512 algorithm designator prefix as The prefix is the ASN.1 DER SHA-512 algorithm designator prefix as
specified in PKCS #1 v2.1 [RFC3447]: specified in PKCS #1 v2.1 [RFC3447]:
hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40 hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40
4. Deployment Considerations 4. Deployment Considerations
4.1. Key Sizes 4.1. Key Sizes
skipping to change at page 6, line 5 skipping to change at page 5, line 35
RSA/SHA256 or RSA/SHA512 will have the same size as those produced RSA/SHA256 or RSA/SHA512 will have the same size as those produced
with RSA/SHA1, if the keys have the same length. with RSA/SHA1, 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 resource DNSSEC aware implementations SHOULD be able to support RRSIG resource
records with the RSA/SHA-2 algorithms. records with the RSA/SHA-2 algorithms.
5.2. Support for NSEC3 Denial of Existence
Note that these algorithms have no aliases to signal NSEC3 [RFC5155]
denial of existence. The aliases mechanism used in RFC 5155 was to
protect implementations predating that RFC from encountering records
they could not know about.
5.2.1. NSEC3 in Authoritative servers
An authoritative server that does not implement NSEC3 MAY still serve
zones that use RSA/SHA2 with NSEC.
5.2.2. NSEC3 in Validators
A DNSSEC validator that implements RSA/SHA2 MUST be able to handle
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/
SHA512 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
Value Algorithm Mnemonic Signing References Value Algorithm Mnemonic Signing References
{TBA1} RSA/SHA-256 RSASHA256 y {this memo} {TBA1} RSA/SHA-256 RSASHA256 y {this memo}
{TBA2} RSA/SHA-256-NSEC3 RSASHA256NSEC3 y {this memo} {TBA2} RSA/SHA-512 RSASHA512 y {this memo}
{TBA3} RSA/SHA-512 RSASHA512 y {this memo}
{TBA4} RSA/SHA-512-NSEC3 RSASHA512NSEC3 y {this memo}
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
skipping to change at page 9, line 4 skipping to change at line 331
Author's Address Author's Address
Jelte Jansen Jelte Jansen
NLnet Labs NLnet Labs
Kruislaan 419 Kruislaan 419
Amsterdam 1098VA Amsterdam 1098VA
NL NL
Email: jelte@NLnetLabs.nl Email: jelte@NLnetLabs.nl
URI: http://www.nlnetlabs.nl/ URI: http://www.nlnetlabs.nl/
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 15 change blocks. 
29 lines changed or deleted 46 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/