ietf-corpus

rfc-5702

Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC

J. Jansen
date2009-10 streamIETF areaint wgdnsext statusPROPOSED STANDARD pages10 canonicalhttps://www.rfc-editor.org/rfc/rfc5702 doi10.17487/RFC5702 errataview
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). [STANDARDS TRACK]

updated by

Extracted elements (16)

design-rationale §8.1

RSASSA-PKCS1-v1_5 was chosen as the signature scheme to match the one used for RSA/SHA-1 signatures, easing implementation of new hashing algorithms in existing DNSSEC software.

dns, crypto, security

design-rationale §5.2

This document does not define NSEC3 algorithm aliases for RSA/SHA-2 (unlike RFC 5155 for older algorithms) because that aliasing mechanism was specifically designed to protect pre-RFC 5155 implementations, which would not exist for newly defined algorithm numbers.

dns, security

interoperability-note §4.2

RRSIG 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, because signature size depends on key size rather than the hash algorithm.

dns, crypto

normative-requirement §5.2 MUST

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 RFC 5155.

dns, security

normative-requirement §5.2 MAY

An authoritative server that does not implement NSEC3 MAY still serve zones that use RSA/SHA-2 with NSEC denial of existence.

dns, security

normative-requirement §5.1 SHOULD

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.

dns, crypto, security

normative-requirement §2.1 MUST NOT

For RSA/SHA-256 DNSKEY records, the key size MUST NOT be less than 512 bits and MUST NOT be more than 4096 bits, following the interoperability constraint established in RFC 3110.

dns, crypto, security

normative-requirement §2.2 MUST NOT

For RSA/SHA-512 DNSKEY records, the key size MUST NOT be less than 1024 bits and MUST NOT be more than 4096 bits.

dns, crypto, security

protocol-element §2.1

RSA/SHA-256 public keys are stored in DNSKEY RRs with algorithm number 8 (mnemonic: RSASHA256). This algorithm supports zone signing; transaction security standardization is undetermined.

dns, crypto, security

protocol-element §2.2

RSA/SHA-512 public keys are stored in DNSKEY RRs with algorithm number 10 (mnemonic: RSASHA512). This algorithm supports zone signing; transaction security standardization is undetermined.

dns, crypto, security

registry §7

This document adds two entries to the IANA 'DNS SECURITY ALGORITHM NUMBERS' registry: value 8 (RSASHA256, zone signing Y) and value 10 (RSASHA512, zone signing Y), both referencing RFC 5702. Transaction security use is not standardized.

dns, registry, security

security-consideration §8.2

Since each RRSet MUST be signed with each algorithm present in the DNSKEY RRSet at the zone apex (per RFC 4035 Section 2.2), a malicious party cannot filter out RSA/SHA-2 RRSIG records to force use of RSA/SHA-1, providing resilience against algorithm downgrade attacks when validators support RSA/SHA-2.

dns, security, crypto

security-consideration §8.1

Users of DNSSEC are encouraged to deploy SHA-2 as soon as software implementations allow. SHA-2 is considered more resilient to attack than SHA-1, whose strength has been eroded by announced attacks, making SHA-2 the better choice for DNSSEC records.

dns, security, crypto

wire-format §3.1

The ASN.1 DER SHA-256 algorithm designator prefix used in RSA/SHA-256 RRSIG records is: hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20.

dns, crypto

wire-format §3.2

The ASN.1 DER SHA-512 algorithm designator prefix used in RSA/SHA-512 RRSIG records is: hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40.

dns, crypto

wire-format §3

The RRSIG signature field for RSA/SHA-2 uses RSASSA-PKCS1-v1_5: the padded structure is (00 | 01 | FF* | 00 | prefix | hash) raised to the private exponent mod n. The FF octet is repeated until the total length equals the modulus length.

dns, crypto, security