564 lines
19 KiB
Plaintext
564 lines
19 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group J. Jansen
|
||
Request for Comments: 5702 NLnet Labs
|
||
Category: Standards Track October 2009
|
||
|
||
|
||
Use of SHA-2 Algorithms with RSA in
|
||
DNSKEY and RRSIG Resource Records for DNSSEC
|
||
|
||
Abstract
|
||
|
||
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
|
||
Security Extensions (RFC 4033, RFC 4034, and RFC 4035).
|
||
|
||
Status of This Memo
|
||
|
||
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 (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. Code Components extracted from this document must
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Jansen Standards Track [Page 1]
|
||
|
||
RFC 5702 DNSSEC RSA/SHA-2 October 2009
|
||
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction ....................................................2
|
||
2. DNSKEY Resource Records .........................................3
|
||
2.1. RSA/SHA-256 DNSKEY Resource Records ........................3
|
||
2.2. RSA/SHA-512 DNSKEY Resource Records ........................3
|
||
3. RRSIG Resource Records ..........................................3
|
||
3.1. RSA/SHA-256 RRSIG Resource Records .........................4
|
||
3.2. RSA/SHA-512 RRSIG Resource Records .........................4
|
||
4. Deployment Considerations .......................................5
|
||
4.1. Key Sizes ..................................................5
|
||
4.2. Signature Sizes ............................................5
|
||
5. Implementation Considerations ...................................5
|
||
5.1. Support for SHA-2 Signatures ...............................5
|
||
5.2. Support for NSEC3 Denial of Existence ......................5
|
||
6. Examples ........................................................6
|
||
6.1. RSA/SHA-256 Key and Signature ..............................6
|
||
6.2. RSA/SHA-512 Key and Signature ..............................7
|
||
7. IANA Considerations .............................................8
|
||
8. Security Considerations .........................................8
|
||
8.1. SHA-1 versus SHA-2 Considerations for RRSIG
|
||
Resource Records ...........................................8
|
||
8.2. Signature Type Downgrade Attacks ...........................8
|
||
9. Acknowledgments .................................................9
|
||
10. References .....................................................9
|
||
10.1. Normative References ......................................9
|
||
10.2. Informative References ....................................9
|
||
|
||
1. Introduction
|
||
|
||
The Domain Name System (DNS) is the global, hierarchical distributed
|
||
database for Internet Naming. The DNS has been extended to use
|
||
cryptographic keys and digital signatures for the verification of the
|
||
authenticity and integrity of its data. [RFC4033], [RFC4034], and
|
||
[RFC4035] describe these DNS Security Extensions, called DNSSEC.
|
||
|
||
RFC 4034 describes how to store DNSKEY and RRSIG resource records,
|
||
and specifies a list of cryptographic algorithms to use. This
|
||
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
|
||
RRSIG resource records with these hash algorithms.
|
||
|
||
Familiarity with DNSSEC, RSA, and the SHA-2 [FIPS.180-3.2008] family
|
||
of algorithms is assumed in this document.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Jansen Standards Track [Page 2]
|
||
|
||
RFC 5702 DNSSEC RSA/SHA-2 October 2009
|
||
|
||
|
||
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
|
||
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
|
||
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",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||
document are to be interpreted as described in [RFC2119].
|
||
|
||
2. DNSKEY Resource Records
|
||
|
||
The format of the DNSKEY RR can be found in [RFC4034]. [RFC3110]
|
||
describes the use of RSA/SHA-1 for DNSSEC signatures.
|
||
|
||
2.1. RSA/SHA-256 DNSKEY Resource Records
|
||
|
||
RSA public keys for use with RSA/SHA-256 are stored in DNSKEY
|
||
resource records (RRs) with the algorithm number 8.
|
||
|
||
For interoperability, as in [RFC3110], the key size of RSA/SHA-256
|
||
keys MUST NOT be less than 512 bits and MUST NOT be more than 4096
|
||
bits.
|
||
|
||
2.2. RSA/SHA-512 DNSKEY Resource Records
|
||
|
||
RSA public keys for use with RSA/SHA-512 are stored in DNSKEY
|
||
resource records (RRs) with the algorithm number 10.
|
||
|
||
The key size of RSA/SHA-512 keys MUST NOT be less than 1024 bits and
|
||
MUST NOT be more than 4096 bits.
|
||
|
||
3. RRSIG Resource Records
|
||
|
||
The value of the signature field in the RRSIG RR follows the RSASSA-
|
||
PKCS1-v1_5 signature scheme and is calculated as follows. The values
|
||
for the RDATA fields that precede the signature data are specified in
|
||
[RFC4034].
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Jansen Standards Track [Page 3]
|
||
|
||
RFC 5702 DNSSEC RSA/SHA-2 October 2009
|
||
|
||
|
||
hash = SHA-XXX(data)
|
||
|
||
Here XXX is either 256 or 512, depending on the algorithm used, as
|
||
specified in FIPS PUB 180-3; "data" is the wire format data of the
|
||
resource record set that is signed, as specified in [RFC4034].
|
||
|
||
signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
|
||
|
||
Here "|" is concatenation; "00", "01", "FF", and "00" are fixed
|
||
octets of corresponding hexadecimal value; "e" is the private
|
||
exponent of the signing RSA key; and "n" is the public modulus of the
|
||
signing key. The FF octet MUST be repeated the exact number of times
|
||
so that the total length of the concatenated term in parentheses
|
||
equals the length of the modulus of the signer's public key ("n").
|
||
|
||
The "prefix" is intended to make the use of standard cryptographic
|
||
libraries easier. These specifications are taken directly from the
|
||
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
|
||
of [RFC3447]). The prefixes for the different algorithms are
|
||
specified below.
|
||
|
||
3.1. RSA/SHA-256 RRSIG Resource Records
|
||
|
||
RSA/SHA-256 signatures are stored in the DNS using RRSIG resource
|
||
records (RRs) with algorithm number 8.
|
||
|
||
The prefix is the ASN.1 DER SHA-256 algorithm designator prefix, as
|
||
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
|
||
|
||
3.2. RSA/SHA-512 RRSIG Resource Records
|
||
|
||
RSA/SHA-512 signatures are stored in the DNS using RRSIG resource
|
||
records (RRs) with algorithm number 10.
|
||
|
||
The prefix is the ASN.1 DER SHA-512 algorithm designator prefix, as
|
||
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
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Jansen Standards Track [Page 4]
|
||
|
||
RFC 5702 DNSSEC RSA/SHA-2 October 2009
|
||
|
||
|
||
4. Deployment Considerations
|
||
|
||
4.1. Key Sizes
|
||
|
||
Apart from the restrictions in Section 2, this document will not
|
||
specify what size of keys to use. That is an operational issue and
|
||
depends largely on the environment and intended use. A good starting
|
||
point for more information would be NIST SP 800-57 [NIST800-57].
|
||
|
||
4.2. Signature Sizes
|
||
|
||
In this family of signing algorithms, the size of signatures is
|
||
related to the size of the key and not to the hashing algorithm used
|
||
in the signing process. Therefore, RRSIG resource records produced
|
||
with RSA/SHA-256 or RSA/SHA-512 will have the same size as those
|
||
produced with RSA/SHA-1, if the keys have the same length.
|
||
|
||
5. Implementation Considerations
|
||
|
||
5.1. Support for SHA-2 Signatures
|
||
|
||
DNSSEC-aware implementations SHOULD be able to support RRSIG and
|
||
DNSKEY resource records created with the RSA/SHA-2 algorithms as
|
||
defined in this document.
|
||
|
||
5.2. Support for NSEC3 Denial of Existence
|
||
|
||
[RFC5155] defines new algorithm identifiers for existing signing
|
||
algorithms, to indicate that zones signed with these algorithm
|
||
identifiers can use NSEC3 as well as NSEC records to provide denial
|
||
of existence. That mechanism was chosen to protect implementations
|
||
predating RFC 5155 from encountering resource records about which
|
||
they could not know. This document does not define such algorithm
|
||
aliases.
|
||
|
||
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
|
||
algorithm 1, as defined in [RFC5155]. An authoritative server that
|
||
does not implement NSEC3 MAY still serve zones that use RSA/SHA-2
|
||
with NSEC denial of existence.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Jansen Standards Track [Page 5]
|
||
|
||
RFC 5702 DNSSEC RSA/SHA-2 October 2009
|
||
|
||
|
||
6. Examples
|
||
|
||
6.1. RSA/SHA-256 Key and Signature
|
||
|
||
Given a private key with the following values (in Base64):
|
||
|
||
Private-key-format: v1.2
|
||
Algorithm: 8 (RSASHA256)
|
||
Modulus: wVwaxrHF2CK64aYKRUibLiH30KpPuPBjel7E8ZydQW1HYWHfoGm
|
||
idzC2RnhwCC293hCzw+TFR2nqn8OVSY5t2Q==
|
||
PublicExponent: AQAB
|
||
PrivateExponent: UR44xX6zB3eaeyvTRzmskHADrPCmPWnr8dxsNwiDGHzrMKLN+i/
|
||
HAam+97HxIKVWNDH2ba9Mf1SA8xu9dcHZAQ==
|
||
Prime1: 4c8IvFu1AVXGWeFLLFh5vs7fbdzdC6U82fduE6KkSWk=
|
||
Prime2: 2zZpBE8ZXVnL74QjG4zINlDfH+EOEtjJJ3RtaYDugvE=
|
||
Exponent1: G2xAPFfK0KGxGANDVNxd1K1c9wOmmJ51mGbzKFFNMFk=
|
||
Exponent2: GYxP1Pa7CAwtHm8SAGX594qZVofOMhgd6YFCNyeVpKE=
|
||
Coefficient: icQdNRjlZGPmuJm2TIadubcO8X7V4y07aVhX464tx8Q=
|
||
|
||
The DNSKEY record for this key would be:
|
||
|
||
example.net. 3600 IN DNSKEY (256 3 8 AwEAAcFcGsaxxdgiuuGmCkVI
|
||
my4h99CqT7jwY3pexPGcnUFtR2Fh36BponcwtkZ4cAgtvd4Qs8P
|
||
kxUdp6p/DlUmObdk= );{id = 9033 (zsk), size = 512b}
|
||
|
||
With this key, sign the following RRSet, consisting of 1 A record:
|
||
|
||
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
|
||
the expiration date at 00:00 hours on January 1st, 2030, the
|
||
following signature should be created:
|
||
|
||
www.example.net. 3600 IN RRSIG (A 8 3 3600 20300101000000
|
||
20000101000000 9033 example.net. kRCOH6u7l0QGy9qpC9
|
||
l1sLncJcOKFLJ7GhiUOibu4teYp5VE9RncriShZNz85mwlMgNEa
|
||
cFYK/lPtPiVYP4bwg==);{id = 9033}
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Jansen Standards Track [Page 6]
|
||
|
||
RFC 5702 DNSSEC RSA/SHA-2 October 2009
|
||
|
||
|
||
6.2. RSA/SHA-512 Key and Signature
|
||
|
||
Given a private key with the following values (in Base64):
|
||
|
||
Private-key-format: v1.2
|
||
Algorithm: 10 (RSASHA512)
|
||
Modulus: 0eg1M5b563zoq4k5ZEOnWmd2/BvpjzedJVdfIsDcMuuhE5SQ3pf
|
||
Q7qmdaeMlC6Nf8DKGoUPGPXe06cP27/WRODtxXquSUytkO0kJDk
|
||
8KX8PtA0+yBWwy7UnZDyCkynO00Uuk8HPVtZeMO1pHtlAGVnc8V
|
||
jXZlNKdyit99waaE4s=
|
||
PublicExponent: AQAB
|
||
PrivateExponent: rFS1IPbJllFFgFc33B5DDlC1egO8e81P4fFadODbp56V7sphKa6
|
||
AZQCx8NYAew6VXFFPAKTw41QdHnK5kIYOwxvfFDjDcUGza88qbj
|
||
yrDPSJenkeZbISMUSSqy7AMFzEolkk6WSn6k3thUVRgSlqDoOV3
|
||
SEIAsrB043XzGrKIVE=
|
||
Prime1: 8mbtsu9Tl9v7tKSHdCIeprLIQXQLzxlSZun5T1n/OjvXSUtvD7x
|
||
nZJ+LHqaBj1dIgMbCq2U8O04QVcK3TS9GiQ==
|
||
Prime2: 3a6gkfs74d0Jb7yL4j4adAif4fcp7ZrGt7G5NRVDDY/Mv4TERAK
|
||
Ma0TKN3okKE0A7X+Rv2K84mhT4QLDlllEcw==
|
||
Exponent1: v3D5A9uuCn5rgVR7wgV8ba0/KSpsdSiLgsoA42GxiB1gvvs7gJM
|
||
MmVTDu/ZG1p1ZnpLbhh/S/Qd/MSwyNlxC+Q==
|
||
Exponent2: m+ezf9dsDvYQK+gzjOLWYeKq5xWYBEYFGa3BLocMiF4oxkzOZ3J
|
||
PZSWU/h1Fjp5RV7aPP0Vmx+hNjYMPIQ8Y5w==
|
||
Coefficient: Je5YhYpUron/WdOXjxNAxDubAp3i5X7UOUfhJcyIggqwY86IE0Q
|
||
/Bk0Dw4SC9zxnsimmdBXW2Izd8Lwuk8FQcQ==
|
||
|
||
The DNSKEY record for this key would be:
|
||
|
||
example.net. 3600 IN DNSKEY (256 3 10 AwEAAdHoNTOW+et86KuJOWRD
|
||
p1pndvwb6Y83nSVXXyLA3DLroROUkN6X0O6pnWnjJQujX/AyhqFD
|
||
xj13tOnD9u/1kTg7cV6rklMrZDtJCQ5PCl/D7QNPsgVsMu1J2Q8g
|
||
pMpztNFLpPBz1bWXjDtaR7ZQBlZ3PFY12ZTSncorffcGmhOL
|
||
);{id = 3740 (zsk), size = 1024b}
|
||
|
||
With this key, sign the following RRSet, consisting of 1 A record:
|
||
|
||
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
|
||
the expiration date at 00:00 hours on January 1st, 2030, the
|
||
following signature should be created:
|
||
|
||
www.example.net. 3600 IN RRSIG (A 10 3 3600 20300101000000
|
||
20000101000000 3740 example.net. tsb4wnjRUDnB1BUi+t
|
||
6TMTXThjVnG+eCkWqjvvjhzQL1d0YRoOe0CbxrVDYd0xDtsuJRa
|
||
eUw1ep94PzEWzr0iGYgZBWm/zpq+9fOuagYJRfDqfReKBzMweOL
|
||
DiNa8iP5g9vMhpuv6OPlvpXwm9Sa9ZXIbNl1MBGk0fthPgxdDLw
|
||
=);{id = 3740}
|
||
|
||
|
||
|
||
Jansen Standards Track [Page 7]
|
||
|
||
RFC 5702 DNSSEC RSA/SHA-2 October 2009
|
||
|
||
|
||
7. IANA Considerations
|
||
|
||
This document updates the IANA registry "DNS SECURITY ALGORITHM
|
||
NUMBERS -- per [RFC4035]" (http://www.iana.org/protocols). The
|
||
following entries are added to the registry:
|
||
|
||
Zone Trans.
|
||
Value Description Mnemonic Signing Sec. References
|
||
8 RSA/SHA-256 RSASHA256 Y * RFC 5702
|
||
10 RSA/SHA-512 RSASHA512 Y * RFC 5702
|
||
|
||
* There has been no determination of standardization of the use of
|
||
this algorithm with Transaction Security.
|
||
|
||
8. Security Considerations
|
||
|
||
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
|
||
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
|
||
being eroded by recently announced attacks. Regardless of whether or
|
||
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
|
||
DNSSEC records.
|
||
|
||
SHA-2 is considered sufficiently strong for the immediate future, but
|
||
predictions about future development in cryptography and
|
||
cryptanalysis are beyond the scope of this document.
|
||
|
||
The signature scheme RSASSA-PKCS1-v1_5 is chosen to match the one
|
||
used for RSA/SHA-1 signatures. This should ease implementation of
|
||
the new hashing algorithms in DNSSEC software.
|
||
|
||
8.2. Signature Type Downgrade Attacks
|
||
|
||
Since each RRSet MUST be signed with each algorithm present in the
|
||
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
|
||
validator to use the RSA/SHA-1 signature if both are present in the
|
||
zone. This should provide resilience against algorithm downgrade
|
||
attacks, if the validator supports RSA/SHA-2.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Jansen Standards Track [Page 8]
|
||
|
||
RFC 5702 DNSSEC RSA/SHA-2 October 2009
|
||
|
||
|
||
9. Acknowledgments
|
||
|
||
This document is a minor extension to [RFC4034]. Also, we try to
|
||
follow the documents [RFC3110] and [RFC4509] for consistency. The
|
||
authors of and contributors to these documents are gratefully
|
||
acknowledged for their hard work.
|
||
|
||
The following people provided additional feedback and text: Jaap
|
||
Akkerhuis, Mark Andrews, Roy Arends, Rob Austein, Francis Dupont,
|
||
Miek Gieben, Alfred Hoenes, Paul Hoffman, Peter Koch, Scott Rose,
|
||
Michael St. Johns, and Wouter Wijngaards.
|
||
|
||
10. References
|
||
|
||
10.1. Normative References
|
||
|
||
[FIPS.180-3.2008]
|
||
National Institute of Standards and Technology, "Secure
|
||
Hash Standard", FIPS PUB 180-3, October 2008.
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
|
||
Name System (DNS)", RFC 3110, May 2001.
|
||
|
||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||
Rose, "DNS Security Introduction and Requirements",
|
||
RFC 4033, March 2005.
|
||
|
||
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||
Rose, "Resource Records for the DNS Security Extensions",
|
||
RFC 4034, March 2005.
|
||
|
||
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||
Rose, "Protocol Modifications for the DNS Security
|
||
Extensions", RFC 4035, March 2005.
|
||
|
||
10.2. Informative References
|
||
|
||
[NIST800-57]
|
||
Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
|
||
"Recommendations for Key Management", NIST SP 800-57,
|
||
March 2007.
|
||
|
||
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
|
||
Standards (PKCS) #1: RSA Cryptography Specifications
|
||
Version 2.1", RFC 3447, February 2003.
|
||
|
||
|
||
|
||
Jansen Standards Track [Page 9]
|
||
|
||
RFC 5702 DNSSEC RSA/SHA-2 October 2009
|
||
|
||
|
||
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
|
||
(DS) Resource Records (RRs)", RFC 4509, May 2006.
|
||
|
||
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
|
||
Security (DNSSEC) Hashed Authenticated Denial of
|
||
Existence", RFC 5155, March 2008.
|
||
|
||
Author's Address
|
||
|
||
Jelte Jansen
|
||
NLnet Labs
|
||
Science Park 140
|
||
1098 XG Amsterdam
|
||
NL
|
||
|
||
EMail: jelte@NLnetLabs.nl
|
||
URI: http://www.nlnetlabs.nl/
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Jansen Standards Track [Page 10]
|
||
|