draft-ietf-dnsext-dnssec-rsasha256-14.txt | rfc5702.txt | |||
---|---|---|---|---|
DNS Extensions working group J. Jansen | Network Working Group J. Jansen | |||
Internet-Draft NLnet Labs | Request for Comments: 5702 NLnet Labs | |||
Intended status: Standards Track June 04, 2009 | Category: Standards Track October 2009 | |||
Expires: December 6, 2009 | ||||
Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records | ||||
for DNSSEC | ||||
draft-ietf-dnsext-dnssec-rsasha256-14 | ||||
Status of this Memo | ||||
This Internet-Draft is submitted to IETF in full conformance with the | ||||
provisions of BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | Use of SHA-2 Algorithms with RSA in | |||
Task Force (IETF), its areas, and its working groups. Note that | DNSKEY and RRSIG Resource Records for DNSSEC | |||
other groups may also distribute working documents as Internet- | ||||
Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | Abstract | |||
and may be updated, replaced, or obsoleted by other documents at any | ||||
time. It is inappropriate to use Internet-Drafts as reference | ||||
material or to cite them other than as "work in progress." | ||||
The list of current Internet-Drafts can be accessed at | This document describes how to produce RSA/SHA-256 and RSA/SHA-512 | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | DNSKEY and RRSIG resource records for use in the Domain Name System | |||
Security Extensions (RFC 4033, RFC 4034, and RFC 4035). | ||||
The list of Internet-Draft Shadow Directories can be accessed at | Status of This Memo | |||
http://www.ietf.org/shadow.html. | ||||
This Internet-Draft will expire on December 6, 2009. | This document specifies an Internet standards track protocol for the | |||
Internet community, and requests discussion and suggestions for | ||||
improvements. Please refer to the current edition of the "Internet | ||||
Official Protocol Standards" (STD 1) for the standardization state | ||||
and status of this protocol. Distribution of this memo is unlimited. | ||||
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 | |||
publication of this document (http://trustee.ietf.org/license-info). | (http://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | ||||
Abstract | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | ||||
described in the BSD License. | ||||
This document describes how to produce RSA/SHA-256 and RSA/SHA-512 | RFC 5702 DNSSEC RSA/SHA-2 October 2009 | |||
DNSKEY and RRSIG resource records for use in the Domain Name System | ||||
Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction ....................................................2 | |||
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 ..........................................3 | |||
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. Support for NSEC3 Denial of Existence ......................5 | |||
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 6. Examples ........................................................6 | |||
6.1. RSA/SHA-256 Key and Signature . . . . . . . . . . . . . . 6 | 6.1. RSA/SHA-256 Key and Signature ..............................6 | |||
6.2. RSA/SHA-512 Key and Signature . . . . . . . . . . . . . . 7 | 6.2. RSA/SHA-512 Key and Signature ..............................7 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 7. IANA Considerations .............................................8 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | 8. Security Considerations .........................................8 | |||
8.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource | 8.1. SHA-1 versus SHA-2 Considerations for RRSIG | |||
Records . . . . . . . . . . . . . . . . . . . . . . . . . 8 | Resource Records ...........................................8 | |||
8.2. Signature Type Downgrade Attacks . . . . . . . . . . . . . 8 | 8.2. Signature Type Downgrade Attacks ...........................8 | |||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 | 9. Acknowledgments .................................................9 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 10. References .....................................................9 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 | 10.1. Normative References ......................................9 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 9 | 10.2. Informative References ....................................9 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 | ||||
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. [RFC4033], [RFC4034], and | |||
[RFC4034], and RFC 4035 [RFC4035] describe these DNS Security | [RFC4035] describe these DNS Security Extensions, called DNSSEC. | |||
Extensions, called DNSSEC. | ||||
RFC 4034 describes how to store DNSKEY and RRSIG resource records, | RFC 4034 describes how to store DNSKEY and RRSIG resource records, | |||
and specifies a list of cryptographic algorithms to use. This | and specifies a list of cryptographic algorithms to use. This | |||
document extends that list with the algorithms RSA/SHA-256 and RSA/ | document extends that list with the algorithms RSA/SHA-256 and RSA/ | |||
SHA-512, and specifies how to store DNSKEY data and how to produce | SHA-512, and specifies how to store DNSKEY data and how to produce | |||
RRSIG resource records with these hash algorithms. | RRSIG resource records with these hash algorithms. | |||
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. | |||
RFC 5702 DNSSEC RSA/SHA-2 October 2009 | ||||
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 | 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 | 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 | 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. | 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 [RFC4034]. [RFC3110] | |||
3110 [RFC3110] describes the use of RSA/SHA-1 for DNSSEC signatures. | 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 8. | |||
For interoperability, as in RFC 3110 [RFC3110], the key size of RSA/ | For interoperability, as in [RFC3110], the key size of RSA/SHA-256 | |||
SHA-256 keys MUST NOT be less than 512 bits, and MUST NOT be more | keys MUST NOT be less than 512 bits and MUST NOT be more than 4096 | |||
than 4096 bits. | 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 {TBA2}. | resource records (RRs) with the algorithm number 10. | |||
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 | |||
values for the RDATA fields that precede the signature data are | for the RDATA fields that precede the signature data are specified in | |||
specified in RFC 4034 [RFC4034]. | [RFC4034]. | |||
RFC 5702 DNSSEC RSA/SHA-2 October 2009 | ||||
hash = SHA-XXX(data) | hash = SHA-XXX(data) | |||
Here XXX is either 256 or 512, depending on the algorithm used, as | Here XXX is either 256 or 512, depending on the algorithm used, as | |||
specified in FIPS PUB 180-3 [FIPS.180-3.2008], and "data" is the wire | specified in FIPS PUB 180-3; "data" is the wire format data of the | |||
format data of the resource record set that is signed, as specified | resource record set that is signed, as specified in [RFC4034]. | |||
in RFC 4034 [RFC4034]. | ||||
signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) | signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) | |||
Here "|" is concatenation, "00", "01", "FF" and "00" are fixed octets | Here "|" is concatenation; "00", "01", "FF", and "00" are fixed | |||
of corresponding hexadecimal value, "e" is the private exponent of | octets of corresponding hexadecimal value; "e" is the private | |||
the signing RSA key, and "n" is the public modulus of the signing | exponent of the signing RSA key; and "n" is the public modulus of the | |||
key. The FF octet MUST be repeated the exact number of times so that | signing key. The FF octet MUST be repeated the exact number of times | |||
the total length of the concatenated term in parentheses equals the | so that the total length of the concatenated term in parentheses | |||
length of the modulus of the signer's public key ("n"). | equals the length of the modulus of the signer's public key ("n"). | |||
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 of | |||
[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 | of [RFC3447]). The prefixes for the different algorithms are | |||
below. | specified 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}. | records (RRs) with algorithm number 8. | |||
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 {TBA2}. | records (RRs) with algorithm number 10. | |||
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 | |||
RFC 5702 DNSSEC RSA/SHA-2 October 2009 | ||||
4. Deployment Considerations | 4. Deployment Considerations | |||
4.1. Key Sizes | 4.1. Key Sizes | |||
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 to the hashing algorithm used | |||
the signing process. Therefore, RRSIG resource records produced with | in the signing process. Therefore, RRSIG resource records produced | |||
RSA/SHA-256 or RSA/SHA-512 will have the same size as those produced | with RSA/SHA-256 or RSA/SHA-512 will have the same size as those | |||
with RSA/SHA-1, if the keys have the same length. | produced 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 | |||
RFC 5155 [RFC5155] defines new algorithm identifiers for existing | [RFC5155] defines new algorithm identifiers for existing signing | |||
signing algorithms, to indicate that zones signed with these | algorithms, to indicate that zones signed with these algorithm | |||
algorithm identifiers can use NSEC3 as well as NSEC records to | identifiers can use NSEC3 as well as NSEC records to provide denial | |||
provide denial of existence. That mechanism was chosen to protect | of existence. That mechanism was chosen to protect implementations | |||
implementations predating RFC5155 from encountering resource records | predating RFC 5155 from encountering resource records about which | |||
they could not know about. This document does not define such | they could not know. This document does not define such algorithm | |||
algorithm aliases. | aliases. | |||
A DNSSEC validator that implements RSA/SHA-2 MUST be able to validate | A DNSSEC validator that implements RSA/SHA-2 MUST be able to validate | |||
negative answers in the form of both NSEC and NSEC3 with hash | negative answers in the form of both NSEC and NSEC3 with hash | |||
algorithm 1, as defined in [RFC5155]. An authoritative server that | algorithm 1, as defined in [RFC5155]. An authoritative server that | |||
does not implement NSEC3 MAY still serve zones that use RSA/SHA-2 | does not implement NSEC3 MAY still serve zones that use RSA/SHA-2 | |||
with NSEC denial of existence. | with NSEC denial of existence. | |||
RFC 5702 DNSSEC RSA/SHA-2 October 2009 | ||||
6. Examples | 6. Examples | |||
6.1. RSA/SHA-256 Key and Signature | 6.1. RSA/SHA-256 Key and Signature | |||
Given a private key with the following values (in Base64): | Given a private key with the following values (in Base64): | |||
Private-key-format: v1.2 | Private-key-format: v1.2 | |||
Algorithm: 8 (RSASHA256) | Algorithm: 8 (RSASHA256) | |||
Modulus: wVwaxrHF2CK64aYKRUibLiH30KpPuPBjel7E8ZydQW1HYWHfoGm | Modulus: wVwaxrHF2CK64aYKRUibLiH30KpPuPBjel7E8ZydQW1HYWHfoGm | |||
idzC2RnhwCC293hCzw+TFR2nqn8OVSY5t2Q== | idzC2RnhwCC293hCzw+TFR2nqn8OVSY5t2Q== | |||
skipping to change at page 6, line 42 | skipping to change at page 6, line 40 | |||
kxUdp6p/DlUmObdk= );{id = 9033 (zsk), size = 512b} | kxUdp6p/DlUmObdk= );{id = 9033 (zsk), size = 512b} | |||
With this key, sign the following RRSet, consisting of 1 A record: | With this key, sign the following RRSet, consisting of 1 A record: | |||
www.example.net. 3600 IN A 192.0.2.91 | www.example.net. 3600 IN A 192.0.2.91 | |||
If the inception date is set at 00:00 hours on January 1st, 2000, and | If the inception date is set at 00:00 hours on January 1st, 2000, and | |||
the expiration date at 00:00 hours on January 1st, 2030, the | the expiration date at 00:00 hours on January 1st, 2030, the | |||
following signature should be created: | following signature should be created: | |||
www.example.net. 3600 IN RRSIG (A 8 3 3600 20300101000000 | www.example.net. 3600 IN RRSIG (A 8 3 3600 20300101000000 | |||
20000101000000 9033 example.net. kRCOH6u7l0QGy9qpC9 | 20000101000000 9033 example.net. kRCOH6u7l0QGy9qpC9 | |||
l1sLncJcOKFLJ7GhiUOibu4teYp5VE9RncriShZNz85mwlMgNEa | l1sLncJcOKFLJ7GhiUOibu4teYp5VE9RncriShZNz85mwlMgNEa | |||
cFYK/lPtPiVYP4bwg== ;{id = 9033} | cFYK/lPtPiVYP4bwg==);{id = 9033} | |||
RFC 5702 DNSSEC RSA/SHA-2 October 2009 | ||||
6.2. RSA/SHA-512 Key and Signature | 6.2. RSA/SHA-512 Key and Signature | |||
Given a private key with the following values (in Base64): | Given a private key with the following values (in Base64): | |||
Private-key-format: v1.2 | Private-key-format: v1.2 | |||
Algorithm: 10 (RSASHA512) | Algorithm: 10 (RSASHA512) | |||
Modulus: 0eg1M5b563zoq4k5ZEOnWmd2/BvpjzedJVdfIsDcMuuhE5SQ3pf | Modulus: 0eg1M5b563zoq4k5ZEOnWmd2/BvpjzedJVdfIsDcMuuhE5SQ3pf | |||
Q7qmdaeMlC6Nf8DKGoUPGPXe06cP27/WRODtxXquSUytkO0kJDk | Q7qmdaeMlC6Nf8DKGoUPGPXe06cP27/WRODtxXquSUytkO0kJDk | |||
8KX8PtA0+yBWwy7UnZDyCkynO00Uuk8HPVtZeMO1pHtlAGVnc8V | 8KX8PtA0+yBWwy7UnZDyCkynO00Uuk8HPVtZeMO1pHtlAGVnc8V | |||
skipping to change at page 8, line 5 | skipping to change at page 8, line 5 | |||
the expiration date at 00:00 hours on January 1st, 2030, the | the expiration date at 00:00 hours on January 1st, 2030, the | |||
following signature should be created: | following signature should be created: | |||
www.example.net. 3600 IN RRSIG (A 10 3 3600 20300101000000 | www.example.net. 3600 IN RRSIG (A 10 3 3600 20300101000000 | |||
20000101000000 3740 example.net. tsb4wnjRUDnB1BUi+t | 20000101000000 3740 example.net. tsb4wnjRUDnB1BUi+t | |||
6TMTXThjVnG+eCkWqjvvjhzQL1d0YRoOe0CbxrVDYd0xDtsuJRa | 6TMTXThjVnG+eCkWqjvvjhzQL1d0YRoOe0CbxrVDYd0xDtsuJRa | |||
eUw1ep94PzEWzr0iGYgZBWm/zpq+9fOuagYJRfDqfReKBzMweOL | eUw1ep94PzEWzr0iGYgZBWm/zpq+9fOuagYJRfDqfReKBzMweOL | |||
DiNa8iP5g9vMhpuv6OPlvpXwm9Sa9ZXIbNl1MBGk0fthPgxdDLw | DiNa8iP5g9vMhpuv6OPlvpXwm9Sa9ZXIbNl1MBGk0fthPgxdDLw | |||
=);{id = 3740} | =);{id = 3740} | |||
RFC 5702 DNSSEC RSA/SHA-2 October 2009 | ||||
7. IANA Considerations | 7. 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/protocols). The | |||
(http://www.iana.org/assignments/dns-sec-alg-numbers). The following | following entries are added to the registry: | |||
entries are added to the registry: | ||||
Zone Trans. | Zone Trans. | |||
Value Description Mnemonic Signing Sec. References | Value Description Mnemonic Signing Sec. References | |||
{TBA1} RSA/SHA-256 RSASHA256 y * {this memo} | 8 RSA/SHA-256 RSASHA256 Y * RFC 5702 | |||
{TBA2} RSA/SHA-512 RSASHA512 y * {this memo} | 10 RSA/SHA-512 RSASHA512 Y * RFC 5702 | |||
* There has been no determination of standardization of the use of this | * There has been no determination of standardization of the use of | |||
algorithm with Transaction Security. | this algorithm with Transaction Security. | |||
8. Security Considerations | 8. Security Considerations | |||
8.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource Records | 8.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 | |||
time of this writing) that SHA-2 is the better choice for use in | time of this writing) that SHA-2 is the better choice for use in | |||
DNSSEC records. | DNSSEC records. | |||
SHA-2 is considered sufficiently strong for the immediate future, but | SHA-2 is considered sufficiently strong for the immediate future, but | |||
predictions about future development in cryptography and | predictions about future development in cryptography and | |||
cryptanalysis are beyond the scope of this document. | cryptanalysis are beyond the scope of this document. | |||
The signature scheme RSASSA-PKCS1-v1_5 is chosen to match the one | The signature scheme RSASSA-PKCS1-v1_5 is chosen to match the one | |||
used for RSA/SHA-1 signatures. This should ease implementation of | used for RSA/SHA-1 signatures. This should ease implementation of | |||
the new hashing algorithms in DNSSEC software. | the new hashing algorithms in DNSSEC software. | |||
8.2. Signature Type Downgrade Attacks | 8.2. Signature Type Downgrade Attacks | |||
Since each RRSet MUST be signed with each algorithm present in the | Since each RRSet MUST be signed with each algorithm present in the | |||
DNSKEY RRSet at the zone apex (see [RFC4035] Section 2.2), a | DNSKEY RRSet at the zone apex (see Section 2.2 of [RFC4035]), a | |||
malicious party cannot filter out the RSA/SHA-2 RRSIG, and force the | malicious party cannot filter out the RSA/SHA-2 RRSIG and force the | |||
validator to use the RSA/SHA-1 signature if both are present in the | validator to use the RSA/SHA-1 signature if both are present in the | |||
zone. This should provide resilience against algorithm downgrade | zone. This should provide resilience against algorithm downgrade | |||
attacks, if the validator supports RSA/SHA-2. | attacks, if the validator supports RSA/SHA-2. | |||
RFC 5702 DNSSEC RSA/SHA-2 October 2009 | ||||
9. Acknowledgments | 9. Acknowledgments | |||
This document is a minor extension to RFC 4034 [RFC4034]. Also, we | This document is a minor extension to [RFC4034]. Also, we try to | |||
try to follow the documents RFC 3110 [RFC3110] and RFC 4509 [RFC4509] | follow the documents [RFC3110] and [RFC4509] for consistency. The | |||
for consistency. The authors of and contributors to these documents | authors of and contributors to these documents are gratefully | |||
are gratefully acknowledged for their hard work. | acknowledged for their hard work. | |||
The following people provided additional feedback and text: Jaap | The following people provided additional feedback and text: Jaap | |||
Akkerhuis, Mark Andrews, Roy Arends, Rob Austein, Francis Dupont, | Akkerhuis, Mark Andrews, Roy Arends, Rob Austein, Francis Dupont, | |||
Miek Gieben, Alfred Hoenes, Paul Hoffman, Peter Koch, Michael St. | Miek Gieben, Alfred Hoenes, Paul Hoffman, Peter Koch, Scott Rose, | |||
Johns, Scott Rose and Wouter Wijngaards. | Michael St. Johns, and Wouter Wijngaards. | |||
10. References | 10. References | |||
10.1. Normative References | 10.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 | |||
Requirement Levels", RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain | [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain | |||
Name System (DNS)", RFC 3110, May 2001. | Name System (DNS)", RFC 3110, May 2001. | |||
[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", | |||
skipping to change at page 10, line 6 | skipping to change at page 10, line 5 | |||
[NIST800-57] | [NIST800-57] | |||
Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, | Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, | |||
"Recommendations for Key Management", NIST SP 800-57, | "Recommendations for Key Management", NIST SP 800-57, | |||
March 2007. | March 2007. | |||
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography | [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography | |||
Standards (PKCS) #1: RSA Cryptography Specifications | Standards (PKCS) #1: RSA Cryptography Specifications | |||
Version 2.1", RFC 3447, February 2003. | Version 2.1", RFC 3447, February 2003. | |||
RFC 5702 DNSSEC RSA/SHA-2 October 2009 | ||||
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer | [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer | |||
(DS) Resource Records (RRs)", RFC 4509, May 2006. | (DS) Resource Records (RRs)", RFC 4509, May 2006. | |||
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS | [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS | |||
Security (DNSSEC) Hashed Authenticated Denial of | Security (DNSSEC) Hashed Authenticated Denial of | |||
Existence", RFC 5155, March 2008. | Existence", RFC 5155, March 2008. | |||
Author's Address | Author's Address | |||
Jelte Jansen | Jelte Jansen | |||
NLnet Labs | NLnet Labs | |||
Kruislaan 419 | Science Park 140 | |||
Amsterdam 1098VA | 1098 XG Amsterdam | |||
NL | NL | |||
Email: jelte@NLnetLabs.nl | EMail: jelte@NLnetLabs.nl | |||
URI: http://www.nlnetlabs.nl/ | URI: http://www.nlnetlabs.nl/ | |||
End of changes. 48 change blocks. | ||||
136 lines changed or deleted | 137 lines changed or added | |||
This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |