Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSECNLnet LabsKruislaan 419Amsterdam1098VANLjelte@NLnetLabs.nlhttp://www.nlnetlabs.nl/
General
DNS Extensions working groupRFCRequest for CommentsI-DInternet-DraftDNSSECRSASHA-256SHA-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 Security Extensions
(DNSSEC, RFC 4033, RFC 4034, and RFC 4035).
The Domain Name System (DNS) is the global
hierarchical distributed database for Internet
Addressing. The DNS has been extended to use
cryptographic keys and digital signatures for the
verification of the integrity of its data. RFC 4033
, RFC 4034
, and RFC 4035
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
family of
algorithms is assumed in this document.
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 format of the DNSKEY RR can be found in RFC 4034
and RFC 3110
.
RSA public keys for use with RSA/SHA-256 are stored
in DNSKEY resource records (RRs) with the algorithm
number {TBA1}.
For use with NSEC3, the algorithm number of
RSA/SHA-256 will be {TBA2}.
The key size for RSA/SHA-256 keys MUST NOT be less
than 512 bits, and MUST NOT be more than 4096 bits.
RSA public keys for use with RSA/SHA-512 are stored
in DNSKEY resource records (RRs) with the algorithm
number {TBA3}.
For use with NSEC3, the algorithm number of
RSA/SHA-512 will be {TBA4}.
The key size for RSA/SHA-512 keys MUST NOT be less
than 1024 bits, and MUST NOT be more than 4096 bits.
The value of the signature field in the RRSIG RR
follow 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 RFC 4034 .
hash = SHA-XXX(data)
Where XXX is either 256 or 512, depending on the
algorithm used.
signature = ( 00 | 01 | FF* | 00 | prefix | hash )
** e (mod n)
Where SHA-XXX is the message digest algorithm as
specified in FIPS PUB 180-2
, "|" 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 maximum number of times so
that the total length of the signature equals the
length of the modulus of the signer's public key
("n"). "data" is the data of the resource record
set that is signed, as specified in RFC 4034
.
The "prefix" is intended to make the use of
standard cryptographic libraries easier. These
specifications are taken directly from the
specification of EMSA-PKCS1-v1_5 encoding in PKCS
#1 v2.1 section 9.2 . The
prefixes for the different algorithms are specified
below.
RSA/SHA-256 signatures are stored in the DNS using
RRSIG resource records (RRs) with algorithm number
{TBA1} for use with NSEC, or {TBA2} for use with
NSEC3.
The prefix is the ASN.1 BER SHA-256 algorithm
designator prefix as specified in PKCS #1 v2.1
:
hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05
00 04 20
RSA/SHA-512 signatures are stored in the DNS using
RRSIG resource records (RRs) with algorithm number
{TBA3} for use with NSEC, or {TBA4} for use with NSEC3.
The prefix is the ASN.1 BER SHA-512 algorithm
designator prefix as specified in PKCS #1 v2.1
:
hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05
00 04 40
Apart from prohibiting RSA/SHA-512 signatures smaller
than 1024 bytes, this document will not specify what
size of keys to use. That is more an operational
issue and depends largely on the environment and
intended use. Some good starting points might be
DNSSEC Operational Practises
, section 3.5, and NIST SP
800-57 Part 1 and
Part 3 .
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 the signing
process. Therefore, RRSIG resource records produced
with RSA/SHA256 or RSA/SHA512 shall have the same size
as those produced with RSA/SHA1, if the keys have the
same length.
DNSSEC aware implementations SHOULD be able to
support RRSIG resource records with the RSA/SHA-2
algorithms.
If both RSA/SHA-2 and RSA/SHA-1 RRSIG resource
records are available for a certain RRset, with a
secure path to their keys, the validator SHOULD
ignore the SHA-1 signature. If the RSA/SHA-2
signature does not verify the data, and the
RSA/SHA-1 signature does, the validator SHOULD mark
the data with the security status from the RSA/SHA-2
signature.
IANA has not yet assigned an algorithm number for
RSA/SHA-256 and RSA/SHA-512.
The algorithm list from RFC 4034 Appendix A.1
is extended with the
following entries:
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.
Since each RRset MUST be signed with each
algorithm present in the DNSKEY RRset at the
zone apex (see
Section 2.2), 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. Together with
the implementation considerations from
of this
document, this provides resilience against
algorithm downgrade attacks, if the validator
supports RSA/SHA-2.
This document is a minor extension to RFC 4034
. Also, we try to follow
the documents RFC 3110 and
RFC 4509 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, Roy Arends, Rob Austein,
Miek Gieben, Alfred Hoenes, Michael St. Johns,
Scott Rose and Wouter Wijngaards.
DNS Security Introduction and RequirementsResource Records for the DNS Security ExtensionsProtocol Modifications for the DNS Security ExtensionsPublic-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1Secure Hash StandardNational Institute of Standards and TechnologyRSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)
Applied Cryptography Second Edition: protocols,
algorithms, and source code in C
Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)DNSSEC Operational PracticesRecommendations for Key Management Part 1: GeneralRecommendations for Key Management Part 3: Application-Specific Key Guidance