ietf-corpus

rfc-6944

Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status

S. Rose
date2013-04 streamIETF areaint wgdnsext statusPROPOSED STANDARD pages7 canonicalhttps://www.rfc-editor.org/rfc/rfc6944 doi10.17487/RFC6944 errataview
The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. There is currently an IANA registry for these algorithms, but there is no record of the recommended implementation status of each algorithm. This document provides an applicability statement on algorithm implementation status for DNSSEC component software. This document lists each algorithm's status based on the current reference. In the case that an algorithm is specified without an implementation status, this document assigns one. This document updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933.

obsoleted by

updates

Extracted elements (13)

design-rationale §2.4

A single authoritative document model was chosen for algorithm implementation status: rather than allowing incremental updates, any status change or new non-Optional algorithm requires this document to be made obsolete and replaced in its entirety, ensuring implementers always have one canonical reference.

dns, process

design-rationale §2.2

ECDSAP256SHA256 and ECDSAP384SHA384 are 'Recommended to Implement' because ECDSA offers a perceived similar level of security to RSA-based algorithms but with smaller key sizes, making widespread adoption likely.

dns, crypto

design-rationale §2.2

RSASHA1-NSEC3-SHA1 is 'Recommended to Implement' because many DNSSEC deployments use NSEC3 for authenticated denial of existence, making support for this algorithm important for broad interoperability.

dns, crypto

design-rationale §2.2

RSASHA256 and RSASHA512 are assigned 'Recommended to Implement' because major deployments, including the root zone, use these algorithms. It is expected they will replace older algorithms such as RSA/SHA-1 that have a perceived weakness.

dns, crypto

interoperability-note §2.4

Algorithms registered via the RFC 6014 procedure (which allows algorithm registration outside the standards track) are automatically assigned Optional status because the status table only grants higher statuses to algorithms explicitly listed in this document.

dns, crypto, registry

normative-requirement §2.1 MUST

All implementations MUST be prepared to interoperate with implementations that do or do not implement Optional algorithms. Optional algorithms MAY be implemented at the implementer's discretion.

dns, crypto

normative-requirement §2.2 MUST NOT

RSAMD5 MUST NOT be implemented due to known weaknesses in MD5. This status reaffirms and strengthens the prior 'NOT RECOMMENDED' designation from RFC 4034.

dns, crypto, security

normative-requirement §2.3 MUST

RSASHA1 MUST be implemented to interoperate with other implementations of DNSSEC. This is the sole algorithm with 'Must Implement' status, consistent with RFC 4034.

dns, crypto, security

normative-requirement §2.3 SHOULD

RSASHA256, RSASHA512, RSASHA1-NSEC3-SHA1, ECDSAP256SHA256, and ECDSAP384SHA384 each carry 'Recommended to Implement' status, meaning implementations SHOULD implement them to improve utility and interoperability.

dns, crypto, security

protocol-element §2.1

Four implementation status categories are defined for DNSSEC algorithms: 'Must Implement' (required for interoperability), 'Must Not Implement' (known weaknesses), 'Recommended to Implement' (SHOULD implement), and 'Optional' (MAY implement). Any algorithm not explicitly listed in the status table defaults to Optional.

dns, crypto, registry

protocol-element §2.3

The DNSSEC algorithm implementation status table assigns: Must Implement — RSASHA1; Must Not Implement — RSAMD5; Recommended to Implement — RSASHA256, RSASHA1-NSEC3-SHA1, RSASHA512, ECDSAP256SHA256, ECDSAP384SHA384; Optional — DSASHA1, DH, DSA-NSEC3-SHA1, GOST-ECC, and any other registered algorithm not listed.

dns, crypto

registry §3

This document establishes implementation status assignments as a normative reference for the IANA 'DNS Security Algorithm Numbers' registry. The registry is maintained at http://www.iana.org/assignments/dns-sec-alg-numbers and this document is listed as a reference for the registry itself.

dns, registry, crypto

security-consideration §4

RSAMD5's prior 'NOT RECOMMENDED' status from RFC 4034 has been strengthened to 'Must Not Implement' due to known weaknesses in the MD5 hash function. This document does not introduce new security considerations beyond consolidating and clarifying existing algorithm statuses.

dns, crypto, security