[Servercert-wg] [Ext] Re: Discussion Period Begins - Ballot SC-080 V1: "Sunsetting use of WHOIS to identify Domain Contacts"

[Francisco Arias]

Hi all,

Regarding the proposal to sunset the use of WHOIS to identify domain contacts, I would like to make the following points.

In the domain name space, there is a distinction between WHOIS data (which we prefer to call registration data) and the WHOIS protocol. The WHOIS protocol is very old, even predating DNS. However, registration data can be served over the Registration Data Access Protocol (RDAP), which is a modern REST-style protocol using JSON and HTTPS.

Unlike the WHOIS protocol, RDAP has a formal method for finding an authoritative server. This is defined in RFC 9224 [1]. In summary, each TLD registers a set of RDAP servers with IANA and RDAP clients use this information to find the authoritative server for TLDs [2]. Because of this formalized mechanism operated by the IANA, RDAP is less susceptible than the WHOIS protocol for the exploit noted by WatchTower Labs.

Finally, with the recent ratification of the ICANN RDAP Amendment [3], most gTLD registries and all registrars will no longer be under obligation to operate WHOIS services starting 28 January 2025. All will be under obligation to operate RDAP services conformant to the ICANN gTLD Profile [4].

I hope you find this information useful in your deliberations. I’d love to have one of our RDAP subject matter experts (Andy Newton, copied here) added to this mailing list to help with any other questions you may have on this topic. Is this something we can do?

Francisco Arias,
VP, GDS Technical Services
ICANN

[1] https://www.rfc-editor.org/info/rfc9224
[2] https://data.iana.org/rdap/dns.json
[3] https://www.icann.org/en/blogs/details/icann-board-approves-rdap-amendments-04-05-2023-en
[4] https://www.icann.org/gtld-rdap-profile


On 9/16/24, 13:40, "Servercert-wg on behalf of Mike Shaver via Servercert-wg" <servercert-wg-bounces at cabforum.org<mailto:servercert-wg-bounces at cabforum.org> on behalf of servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>> wrote:

Hi Dimitris,

On Mon, Sep 16, 2024 at 2:07 PM Dimitris Zacharopoulos (HARICA) via Servercert-wg <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>> wrote:
Is there feedback about the number of TLDs and possible certificate volumes that might be affected by this attack?

The majority of validations performed by CAs using WHOIS is done in gTLDs which have decent rules for monitoring and supervising their operators. The biggest issue is with ccTLDs, which in majority work ok. Unfortunately, most of them do not disclose email contact information, making them unusable for Domain Validation.

I’ll admit that I am not very familiar with how gTLD operators manage their Whois services, or ensure prompt update when domains lapse or similar. Could you provide some more detail about the “decent rules” in place, and how they align with the general standard of hygiene and reliability that is required of other DCV methods? As far as I can tell there isn’t even a provision for server authentication of the WHOIS protocol, meaning that it could be subverted by any MITM or DNS-poisoning adversary, for any domain.

As an example, we recently saw a CA reissue certificates because the (very-widely-relied-upon) Google DNS service they used for domain validation did not *guarantee* that it validated DNSSEC. That is an appropriately high level of care for web PKI certificates, IMO.

Why are we causing such a large disturbance as if the Global Internet is unsafe by this attack when the impact is 1 or 2 vanity TLDs for which mitigations exist (like, use a better library or use the latest updated list from IANA)?

I don’t see how using the updated list from IANA (updated how often and with what latency) overcomes the weaknesses in WHOIS itself, but I also don’t think that we should be treating TLDs differently in terms of the standards of authentication required for obtaining a certificate. As far as I know, no CA has ever tried to make the argument that an incident related to certificate issuance was of lesser import or urgency because it was for a little-used service or domain. I assume (and indeed hope) that such an argument would be ill-received by the root programs. I don’t expect that relying parties grade the web PKI’s assurances on a curve based on what domain they’re connecting to, either. And there is of course no telling which TLD will become “hot” for popular services at any time (as happened with .io and .ai for example, or even .rs).

I may be misunderstanding your argument, though. Are you not saying that it’s no big deal if someone other than the current domain owner can get a certificate for a domain, as long as it’s a “minor” TLD?

That plea for domain equality aside, I think describing .mobi as a “vanity” domain is ahistorical, given its origins and two-decade history.  “amazon.mobi<http://amazon.mobi>” was registered in 2006 and remains active to this day; I expect that it has received a fair bit of traffic from users intending to reach Amazon. The .mobi domain seems to have some level of control applied to who can register what, because google.mobi<http://google.mobi> didn’t exist except when the service was under the security researchers’ control.

Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240916/e6dbb957/attachment-0001.html>