--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
git.samba.org / tridge / bind9.git / blobdiff