ietf-corpus

rfc-9157

Revised IANA Considerations for DNSSEC

P. Hoffman
date2021-12 streamIETF areaops wgdnsop statusPROPOSED STANDARD pages5 canonicalhttps://www.rfc-editor.org/rfc/rfc9157 doi10.17487/RFC9157
This document changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries. It updates RFC 6014 to include hash algorithms for Delegation Signer (DS) records and NextSECure version 3 (NSEC3) parameters (for Hashed Authenticated Denial of Existence). It also updates RFCs 5155 and 6014, which have requirements for DNSSEC algorithms, and updates RFC 8624 to clarify the implementation recommendation related to the algorithms described in RFCs that are not on the standards track. The rationale for these changes is to bring the requirements for DS records and hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms.

updated by

updates

Extracted elements (9)

design-rationale §1

RFC 6014 reduced DNSSEC cryptographic algorithm registration requirements from 'Standards Action' to 'RFC Required', but the corresponding IANA registries for DS hash algorithms and NSEC3 hash algorithms were left at 'Standards Action'. RFC 9157 addresses this inconsistency by bringing DS and NSEC3 hash algorithm requirements in line with all other DNSSEC cryptographic algorithms.

dns, registry, security

design-rationale §3

RFC 8624's original second paragraph only addressed mandatory-to-implement algorithms and algorithms too weak to recommend, leaving a gap for non-standards-track algorithms. RFC 9157 updates RFC 8624 to explicitly cover all DNSKEY and DS algorithms defined in non-standards-track RFCs, ensuring consistent guidance across the registry.

dns, security

design-rationale §2

The update to RFC 6014 allows any DS hash algorithms, NSEC3 hash algorithms, NSEC3 parameters, and NSEC3 flags that are fully described in an RFC to receive IANA identifiers, rather than requiring a full Standards Action. This lowers the barrier for documenting new algorithms while still requiring an RFC.

dns, registry

interoperability-note §3

RFC 9157 updates RFCs 5155, 6014, and 8624. Implementations relying on RFC 8624 for algorithm implementation guidance must account for the clarified scope that now explicitly includes algorithms defined in non-standards-track RFCs, not only mandatory-to-implement or deprecated algorithms.

dns, security

normative-requirement §3 MAY

Any algorithm listed in the DNSKEY-IANA and DS-IANA registries that is not mentioned in RFC 8624 MAY be implemented. An algorithm is specified as MAY in RFC 8624 only when it has been downgraded from MUST or RECOMMENDED.

dns, security

registry §4

In the 'DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms' registry, the registration procedure for 'Digest Algorithms' has been changed from 'Standards Action' to 'RFC Required', adding RFC 9157 as a reference.

dns, registry

registry §4

In the 'Domain Name System Security (DNSSEC) NextSECure3 (NSEC3) Parameters' registry, the registration procedure for 'DNSSEC NSEC3 Flags', 'DNSSEC NSEC3 Hash Algorithms', and 'DNSSEC NSEC3PARAM Flags' has been changed from 'Standards Action' to 'RFC Required'.

dns, registry

security-consideration §5

Administrators of DNSSEC-signed zones and validating resolvers should not make security decisions based on the contents of IANA registries. With more non-standards-track algorithms potentially appearing in registries, registry presence is an even weaker signal of algorithm safety; security decisions should be based on the security literature.

dns, security, registry

security-consideration §5

Lowering the registration requirements for DNSSEC security algorithms in IANA registries will make it easier to add both good and bad algorithms. The document acknowledges it is impossible to weigh the net security impact of this change.

dns, security, registry