Use of SHA-3 (Keccak) and RSASSA-PSS in DNSSECSIDNMeander 501Arnhem6825 MDThe Netherlandsjelte.jansen@sidn.nlhttps://www.sidn.nl/Internet Systems Consortium950 Charter StreetRedwood City94063CAUSmuks@mukund.orghttps://www.isc.org/
Operations and Management Area
Internet Engineering Task ForceThis document specifies the use of SHA-3 (Keccak) hash
functions in DNSSEC. It also specifies the use of the RSASSA-PSS
signature scheme for RSA keys.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. , , and describe these DNS Security Extensions, called
DNSSEC. described how to store DNSKEY and
RRSIG resource records, and specified a list of cryptographic
algorithms to use. It was updated by to
add the SHA-2 family of hash algorithms using the
RSASSA-PKCS1-v1_5 signature scheme .PKCS #1 v2.1 introduced RSASSA-PSS
which is a much better signature scheme than
RSASSA-PKCS1-v1_5. The main advantage of RSASSA-PSS over
RSASSA-PKCS1-v1_5 is that analysis can relate its security to that
of the RSA problem (Section 8.1 of ),
whereas the connection of RSASSA-PKCS1-v1_5 to the RSA problem has
not been proved. With RSASSA-PSS, an attacker also does not know
in advance what the encoded message EM will be due to the use of
random salt that makes fault analysis attacks more difficult to
mount. Although no attacks are known against RSASSA-PKCS1-v1_5, in
the interest of increased robustness, RSASSA-PSS is REQUIRED in
new applications (Section 8 of ).SHA-3 is a family of hash functions based on the cryptographic
primitive family Keccak. states:
"The four SHA-3 hash functions in this Standard supplement the
hash functions that are specified in : SHA-1 and the SHA-2 family. Together,
both Standards provide resilience against future advances in hash
function analysis, because they rely on fundamentally different
design principles." Now that SHA-1's security is known to be
weakened and the SHA-2 hash algorithms are currently the last line
of defence for use with RSA in DNSKEYs, and in DS records, it is
sensible to introduce the SHA-3 hash function family to DNSSEC now
to prepare for any eventuality. The SHA-3 hash function family
uses a sponge construction algorithm that is different from the
SHA-2 hash function family which uses a Merkle-Damgaerd
construction, so the possibility that an attack on SHA-2 will
affect SHA-3 or vice versa is unlikely.This document extends the list of DNSKEY algorithms with the
RSASSA-PSS signature scheme using the
SHA-2 and SHA-3 family of hash functions. It also adds DNSKEY
algorithms for ECDSA using the SHA-3 family of hash functions. first described the use of DS
resource records. It was updated by and
to add SHA-256 and SHA-384 digest types
respectively. This document extends that list with the SHA-3
algorithms SHA3-256 and SHA3-384.Familiarity with DNSSEC, RSA, ECDSA, and the SHA-2 and SHA-3 hash function families is assumed in this document.To refer to SHA2-256 and SHA2-512, this document will use the
name SHA-2. Similarly, to refer to SHA3-256, SHA3-384, and
SHA3-512, this document will use the name SHA-3. This is done to
improve readability. When a part of text is specific for a
particular SHA-2 or SHA-3 hash function, their specific names are
used. The same goes for RSA/SHA3-256 and RSA/SHA3-512 which will
be grouped using the name RSA/SHA-2, and RSA/SHA3-256,
RSA/SHA3-384, and RSA/SHA3-512, which will be grouped using the
name RSA/SHA-3.The SHA2-224, SHA2-384, and SHA3-224 algorithms are not used in
RSASSA-PSS DNSKEYs and RRSIGs. The SHA3-512 algorithm is not used
in ECDSA with SHA-3. The SHA3-224 and SHA3-512 algorithms are not
used as DS digest types.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 .An experimental BIND implementation of this draft can be
found in the "sha3" branch in the git repository at:
https://github.com/muks/bind9There is also an experimental implementation based on the
ldns library, which can be found in the "sha3_and_pss" branch
in the git repository at https://github.com/tjeb/ldns.These can be used to check for interoperability by other DNSSEC
implementations.The format of the DNSKEY RR can be found in . and describe the use of RSASSA-PKCS1-v1_5
signature scheme with SHA-1 and SHA-2 hash functions for DNSSEC
signatures respectively. describes the
use of ECDSA with SHA-2 in DNSSEC.RSA public keys for use with RSASSA-PSS signature scheme using
SHA-2 and SHA-3 hash functions are stored in DNSKEY resource
records (RRs) with the algorithm numbers as specified in .The key size of RSA/SHA2-256 and RSA/SHA3-256 keys MUST NOT be
less than 1024 bits and MUST NOT be more than 4096 bits. This also
satisfies a requirement of the RSASSA-PSS signature scheme that
for a hash function that outputs a 256-bit value, the RSA modulus
be at least 522 bits long.The key size of RSA/SHA3-384 keys MUST NOT be less than 1024
bits and MUST NOT be more than 4096 bits. This also satisfies a
requirement of the RSASSA-PSS signature scheme that for a hash
function that outputs a 384-bit value, the RSA modulus be at least
778 bits long.The key size of RSA/SHA2-512 and RSA/SHA3-512 keys MUST NOT be
less than 1280 bits and MUST NOT be more than 4096 bits. This also
satisfies a requirement of the RSASSA-PSS signature scheme that
for a hash function that outputs a 512-bit value, the RSA modulus
be at least 1034 bits long.P-256 and P-384 ECDSA public keys for use with SHA3-256 and
SHA3-384 hash functions are stored in DNSKEY resource records
(RRs) with the algorithm numbers as specified in .The generation of P-256 and P-384 ECDSA keys follows the same
method as for .For signature calculation, this section uses the specifications
of RSASSA-PSS in PKCS #1 v2.2 (Section 8.1 of ) incorporating EMSA-PSS encoding (Section 9.1
of ).The values for the RRSIG RDATA fields that precede the
signature data are specified in . The
value of the signature field in the RRSIG RDATA follows the
RSASSA-PSS signature scheme and is calculated as described in
Section 8.1.1 of . The message M used in
signature calculation is the argument to the sign() function as
specified in Section 3.1.8.1 of .Within EMSA-PSS-ENCODE, the hash function "Hash" used is one
among SHA2-256, SHA2-512, SHA3-256, SHA3-384, and SHA3-512 for
RSA/SHA2-256, RSA/SHA2-512, RSA/SHA3-256, RSA/SHA3-384, and
RSA/SHA3-512 respectively.The mask generation function is MGF1 (Section B.2.1. of ) and the hash function used within the mask
generation function is also "Hash".The length of salt in octets MUST be equal to the length of the
output of the hash function "Hash" in octets. The value of salt
SHOULD be random per signature computation. A random salt value
enhances the security of the scheme by affording a "tighter"
security proof. However, the randomness is not critical to
security. See Section 8.1 of for the
tradeoffs in security due to a non-random salt.These RSASSA-PSS signatures are stored in the DNS using RRSIG
resource records (RRs) with algorithm number as specified in .P-256 and P-384 ECDSA signatures using SHA3-256 and SHA3-384
hash functions are stored in the DNS using RRSIG resource
records (RRs) with algorithm number as specified in .The generation of P-256 and P-384 ECDSA/SHA-3 signatures
follows the same method as for , except
the collision-resistant hash function "H" (see Section 10.4 of
) for P-256 and P-384 ECDSA/SHA-3
signatures are SHA3-256 and SHA3-384 respectively.The format of the DS RR can be found in . , , and
describe the use of SHA-1, SHA-256, and
SHA-384 for the DS digest type respectively.The implementation of SHA3-256 in DS RRs follows the
implementation of SHA-256 as specified in except that the underlying algorithm is SHA3-256, the digest
value is 32 bytes long, and the digest type code is specified in
.The implementation of SHA3-384 in DS RRs follows the
implementation of SHA-256 as specified in except that the underlying algorithm is SHA3-384, the digest
value is 48 bytes long, and the digest type code is specified in
.Apart from the restrictions in ,
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 .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/SHA2-256, RSA/SHA2-512, RSA/SHA3-256,
RSA/SHA3-384, or RSA/SHA3-512 will have the same size as those
produced with RSA/SHA-1 and RSA/SHA-2 hash algorithms, if the
keys have the same length.DS RDATA with digest type SHA3-256 has the same size as DS
RDATA with digest type SHA-256 (32 bytes). DS RDATA with digest
type SHA3-384 has the same size as DS RDATA with digest type
SHA-384 (48 bytes). Corresponding to these existing digest
types, it should be possible to understand the impact of the
size of DS RDATA when using the new SHA-3 digest types.DNSSEC-aware implementations SHOULD be able to support RRSIG
and DNSKEY resource records created with the RSA/SHA-2,
RSA/SHA-3, and ECDSA/SHA-3 algorithms defined in this
document.DNSSEC-aware implementations SHOULD be able to support DS
resource records created with the SHA3-256 and SHA3-384
algorithms defined in this document. 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 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 and/or RSA/SHA-3
MUST be able to validate negative answers in the form of both
NSEC and NSEC3 with hash algorithm 1, as defined in . An authoritative server that does not
implement NSEC3 MAY still serve zones that use RSA/SHA-2 or
RSA/SHA-3 with NSEC denial of existence.Given a 1024-bit private key with the following values (in Base64):The DNSKEY record for this key would be:With this key, sign the following zone consisting of 4 RRs:Using RSASSA-PSS salt filled entirely with 0 valued octets,
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 signed zone (with DNSKEY) should be
created:Given a 1280-bit private key with the following values (in Base64):The DNSKEY record for this key would be:With this key, sign the following zone consisting of 4 RRs:Using RSASSA-PSS salt filled entirely with 0 valued octets,
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 signed zone (with DNSKEY) should be
created:Given a 1024-bit private key with the following values (in Base64):The DNSKEY record for this key would be:With this key, sign the following zone consisting of 4 RRs:Using RSASSA-PSS salt filled entirely with 0 valued octets,
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 signed zone (with DNSKEY) should be
created:Given a 1024-bit private key with the following values (in Base64):The DNSKEY record for this key would be:With this key, sign the following zone consisting of 4 RRs:Using RSASSA-PSS salt filled entirely with 0 valued octets,
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 signed zone (with DNSKEY) should be
created:Given a 1280-bit private key with the following values (in Base64):The DNSKEY record for this key would be:With this key, sign the following zone consisting of 4 RRs:Using RSASSA-PSS salt filled entirely with 0 valued octets,
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 signed zone (with DNSKEY) should be
created:Given a private key with the following values (in Base64):The DNSKEY record for this key would be:With this key, sign the following zone consisting of 4 RRs: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 signed zone (with DNSKEY) should be
created:Given a private key with the following values (in Base64):The DNSKEY record for this key would be:With this key, sign the following zone consisting of 4 RRs: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 signed zone (with DNSKEY) should be
created:Given a 1024-bit RSA/SHA-256 DNSKEY with the following contents:The DS record for this key with digest type SHA3-256 would be:Given a 1024-bit RSA/SHA-256 DNSKEY with the following contents:The DS record for this key with digest type SHA3-384 would be:DNSSEC implementations are encouraged to implement the new
algorithms in this document as soon as possible now that SHA-1's
security is known to be degraded and the SHA-2 hash algorithms
are currently the last line of defence for use with RSA in
DNSSEC.Users of DNS software are encouraged to deploy these new
algorithms with DNSSEC when software implementations allow for
it. Users are encouraged to run DNSSEC validator implementations
that support these new algorithms when they are available.The RSASSA-PSS signature scheme and the SHA-3 hash function
family are considered sufficiently strong for the immediate
future, but predictions about future development in cryptography
and cryptanalysis are beyond the scope of this document.Since each RRSet MUST be signed with each algorithm present
in the DNSKEY RRSet at the zone apex (see Section 2.2 of ), a malicious party cannot filter out the
RSASSA-PSS RRSIG and force the validator to use a RSA/SHA-1
signature if both are present in the zone. This should provide
resilience against algorithm downgrade attacks, if the validator
supports RSASSA-PSS.This document updates the IANA registry "Domain Name System
Security (DNSSEC) Algorithm Numbers"
(http://www.iana.org/protocols). The following entries are added
to the registry:No.DescriptionMnemonicZ.S.T.S.Ref.245 [TBD]ECDSA Curve P-256 with SHA3-256ECDSAP256SHA3-256Y*[TBD]256 [TBD]ECDSA Curve P-384 with SHA3-384ECDSAP256SHA3-384Y*[TBD]247 [TBD]RSA/SHA2-256 with RSASSA-PSSRSASHA2-256Y*[TBD]248 [TBD]RSA/SHA2-512 with RSASSA-PSSRSASHA2-512Y*[TBD]249 [TBD]RSA/SHA3-256 with RSASSA-PSSRSASHA3-256Y*[TBD]250 [TBD]RSA/SHA3-384 with RSASSA-PSSRSASHA3-384Y*[TBD]251 [TBD]RSA/SHA3-512 with RSASSA-PSSRSASHA3-512Y*[TBD]This document updates the IANA registry "Delegation Signer (DS)
Resource Record (RR) Type Digest Algorithms"
(http://www.iana.org/protocols). The following entries are added
to the registry:ValueDescriptionStatusReferences252 [TBD]SHA3-256OPTIONAL[TBD]253 [TBD]SHA3-384OPTIONAL[TBD]Thanks to Francis Dupont and Paul Hoffman for review and
suggestions.Secure Hash StandardNational Institute of Standards and TechnologySHA-3 Standard: Permutation-Based Hash and Extendable-Output FunctionsNational Institute of Standards and TechnologyRecommendation for Key Management
draft-muks-dnsop-dnssec-sha3-01
Use RSASSA-PSS instead of RSASSA-PKCS1-v1_5. Specify DNSSEC
algorithms using RSASSA-PSS for SHA-2 hash functions
too. Specify algorithms for ECDSA with SHA-3. Update all
examples. Other fixes.
draft-muks-dnsop-dnssec-sha3-00
Initial draft.