Document degree of security of each TLD from a DNSSEC standpoint

[gnarea]

About the problem

Virtually all TLDs support DNSSEC these days, but the degree of security varies wildly by TLD; for example, some still use insecure algorithms (e.g., .apple uses SHA-1), and some are operated from jurisdictions under repressive regimes (e.g., most Chinese-language gTLDs are operated from China). Additionally, DNSSEC currently lacks key transparency measures.

Domain operators should be aware of these issues when they rely on DNSSEC, but it's really hard to do so today.

Proposed solution

A website where each TLD gets a page with the following:

• A rating (from 1 to 5) of their security (based on the points below). This is probably the only thing that 99% of users will be interested in and should therefore be very prominent.
• Whether it uses insecure algorithms (e.g., SHA-1). Ideally, it should also consider whether it uses any insecure keys (e.g., an RSA key with a modulus less than 2048), but this will be more complicated so it could be something we do later on.
• How trustworthy we consider the operator (aka "backend") to be, based on the factors considered in their respective page (see below).
• Links to external sites (e.g., its ICANNWiki page, its nTLDStats page).

We should also publish a page for each operator/backend and document the following:

• Their jurisdiction. Its Freedom House rating may suffice.
• How transparent their security procedures are (beyond what's mandated by IANA).
• Any credible reports of unmitigated threats or actual exploits.

Open questions

• Should the jurisdiction of the sponsor and/or administrative contact be considered in our assessment? For example, .fans is operated by CentralNIC in London but its sponsor and administrative contacts are in Beijing -- could China theoretically compromise the .fans zone via those Beijing-based companies under exceptional circumstances (e.g., a war)? I'd say 'no' based my conversation with IANA (see below).

Alternatives considered

Adding this information to existing websites, like ICANNWiki or nTLDStats, but it feels completely outside of their current remit.

Additional context

I got in contact with IANA regarding the procedures that IANA and TLD sponsors/administrators/backends must adhere to, and got the following reply from Amy Creamer on 12th August 2022:

1. Does IANA regulate in any way the role of the Sponsoring Organisation, Administrative Contact or Technical Contact for each TLD delegation? RFC 1591 simply mentions these roles.

These roles are defined for country code Top Level Domains (ccTLDs) in the Framework of Interpretation of RFC 1591 at https://ccnso.icann.org/sites/default/files/filefield_46435/foi-final-07oct14-en.pdf, and IANA requires that all applicable ccTLD policies and procedures be met by the ccTLD. For generic top level domains (gTLDs), these roles are contained in contracts the gTLD Registry holds with the Internet Corporation for Assigned Names and Numbers (ICANN). All gTLD contracts are made public and can be found here: https://www.icann.org/en/registry-agreements?first-letter=a&sort-column=top-level-domain&sort-direction=asc&page=1.

2. Does IANA have any mechanism to monitor and/or penalise TLD managers that sign fraudulent DNSSEC records? For example, DS/DNSKEY (for phishing purposes) or NSEC/NSEC3 (for denial of service purposes).

This is not within IANA’s remit.

I will answer #⁠3 and #⁠4 together, below:
3. Does IANA require any specific procedures on the generation, use and eventual destruction of cryptographic key material used by TLD managers for DNSSEC purposes?
4. Are TLD managers required to share their DNSSEC key management procedures with IANA, and if so, can third parties have access to them on demand? These are certainly not made available to the public generally, but I wonder if at least IANA has access to such documents.

There are provisions for DNSSEC in the gTLD Registry contracts with ICANN. The most recent contract can be found at: https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html

In the contract I suggest you review:

“SPECIFICATION 6: REGISTRY INTEROPERABILITY AND CONTINUITY SPECIFICATIONS

DNSSEC. Registry Operator shall sign its TLD zone files implementing Domain Name System Security Extensions (“DNSSEC”). For the absence of doubt, Registry Operator shall sign the zone file of and zone files used for in-bailiwick glue for the TLD’s DNS servers. During the Term, Registry Operator shall comply with RFCs 4033, 4034, 4035, 4509 and their successors, and follow the best practices described in RFC 6781 and its successors. If Registry Operator implements Hashed Authenticated Denial of Existence for DNS Security Extensions, it shall comply with RFC 5155 and its successors. Registry Operator shall accept public-key material from child domain names in a secure manner according to industry best practices. Registry shall also publish in its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants’ public-key material. Registry Ope
 rator shall publish its DPS following the format described in RFC 6841. DNSSEC validation must be active and use the IANA DNS Root Key Signing Key set (available at https://www.iana.org/dnssec/files) as a trust anchor for Registry Operator’s Registry Services making use of data obtained via DNS responses.”

One example of a Registry publishing on its website the DNSSEC Practice Statements (DPS) can be found for .apple here: https://www.apple.com/legal/intellectual-property/tld/dps/

For the case of ccTLDs, they are governed locally within their country for anything that goes beyond the scope of ccTLD policies and procedures.