draft-ietf-dnsext-dnssec-rsasha256-10.txt   draft-ietf-dnsext-dnssec-rsasha256-11.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 January 08, 2009 Intended status: Standards Track February 27, 2009
Expires: July 12, 2009 Expires: August 31, 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-10 draft-ietf-dnsext-dnssec-rsasha256-11
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 July 12, 2009. This Internet-Draft will expire on August 31, 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 Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
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 . . . . . . . . . . . . 3 2.2. RSA/SHA-512 DNSKEY Resource Records . . . . . . . . . . . . 4
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 . . . . . . . . . . . . 4 3.2. RSA/SHA-512 RRSIG Resource Records . . . . . . . . . . . . 5
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. Support for NSEC3 Denial of Existence . . . . . . . . . . . 5
5.2.1. NSEC3 in Authoritative servers . . . . . . . . . . . . 5 5.2.1. NSEC3 in Authoritative servers . . . . . . . . . . . . 6
5.2.2. NSEC3 in Validators . . . . . . . . . . . . . . . . . . 5 5.2.2. NSEC3 in Validators . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
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 29 skipping to change at page 3, line 29
Familiarity with DNSSEC, RSA and the SHA-2 [FIPS.180-3.2008] family Familiarity with DNSSEC, RSA and the SHA-2 [FIPS.180-3.2008] family
of algorithms is assumed in this document. of algorithms is assumed in this document.
To refer to both SHA-256 and SHA-512, this document will use the name To refer to both SHA-256 and SHA-512, this document will use the name
SHA-2. This is done to improve readability. When a part of text is SHA-2. This is done to improve readability. When a part of text is
specific for either SHA-256 or SHA-512, their specific names are specific for either SHA-256 or SHA-512, their specific names are
used. The same goes for RSA/SHA-256 and RSA/SHA-512, which will be used. The same goes for RSA/SHA-256 and RSA/SHA-512, which will be
grouped using the name RSA/SHA-2. grouped using the name RSA/SHA-2.
The term "SHA-2" is not officially defined, but is usually used to
refer to the collection of the algorithms SHA-224, SHA-256, SHA-384
and SHA-512. Since SHA-224 and SHA-384 are not used in DNSSEC, SHA-2
will only refer to SHA-256 and SHA-512 in this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
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
skipping to change at page 5, line 14 skipping to change at page 5, line 19
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
Apart from the restrictions specified in section 2, this document Apart from the restrictions in section 2, this document will not
will not specify what size of keys to use. That is an operational specify what size of keys to use. That is an operational issue and
issue and depends largely on the environment and intended use. A depends largely on the environment and intended use. A good starting
good starting point for more information would be NIST SP 800-57 point for more information would be NIST SP 800-57 [NIST800-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/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 and
records with the RSA/SHA-2 algorithms. DNSKEY resource records created with the RSA/SHA-2 algorithms as
defined in this document.
5.2. Support for NSEC3 Denial of Existence 5.2. Support for NSEC3 Denial of Existence
Note that these algorithms have no aliases to signal NSEC3 [RFC5155] RFC5155 [RFC5155] defines new algorithm identifiers for existing
denial of existence. The aliases mechanism used in RFC 5155 was to signing algorithms, to indicate that zones signed with these
protect implementations predating that RFC from encountering records algorithm identifiers use NSEC3 instead of NSEC records to provide
they could not know about. denial of existence. That mechanism was chosen to protect
implementations predating RFC5155 from encountering resource records
they could not know about. This document does not define such
algorithm aliases, and support for NSEC3 denial of existence is
implicitly signaled with support for one of the algorithms defined in
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. zones that use RSA/SHA2 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/SHA2 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/SHA256 or RSA/
SHA512 as signed with an unknown algorithm, and thus as insecure. SHA512 as signed with an unknown algorithm, and thus as insecure.
6. IANA Considerations 6. IANA Considerations
skipping to change at page 7, line 13 skipping to change at page 7, line 22
attacks, if the validator supports RSA/SHA-2. attacks, if the validator supports RSA/SHA-2.
8. Acknowledgments 8. Acknowledgments
This document is a minor extension to RFC 4034 [RFC4034]. Also, we This document is a minor extension to RFC 4034 [RFC4034]. Also, we
try to follow the documents RFC 3110 [RFC3110] and RFC 4509 [RFC4509] try to follow the documents RFC 3110 [RFC3110] and RFC 4509 [RFC4509]
for consistency. The authors of and contributors to these documents for consistency. The authors of and contributors to these documents
are gratefully acknowledged for their hard work. are gratefully acknowledged for their hard work.
The following people provided additional feedback and text: Jaap The following people provided additional feedback and text: Jaap
Akkerhuis, Roy Arends, Rob Austein, Francis Dupont, Miek Gieben, Akkerhuis, Mark Andrews, Roy Arends, Rob Austein, Francis Dupont,
Alfred Hoenes, Paul Hoffman, Peter Koch, Michael St. Johns, Scott Miek Gieben, Alfred Hoenes, Paul Hoffman, Peter Koch, Michael St.
Rose and Wouter Wijngaards. Johns, Scott Rose and Wouter Wijngaards.
9. References 9. References
9.1. Normative References 9.1. Normative References
[FIPS.180-3.2008] [FIPS.180-3.2008]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-3, October 2008. Hash Standard", FIPS PUB 180-3, October 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 End of changes. 15 change blocks. 
30 lines changed or deleted 39 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/