<div dir="ltr">It is worth adding that ICANN not only requires Whois availability in their agreements with gTLDs, but actually monitors it, so it is unlikely that these could have a non-functioning entry for very long: <a href="https://www.icann.org/en/system/files/files/presentation-slam-13may17-en.pdf">https://www.icann.org/en/system/files/files/presentation-slam-13may17-en.pdf</a><div><br></div><div>In most of these takeover situations, I would assume the Whois server was first offline for an extended period of time.</div><div><br></div><div>I also think the timeline for disallowing Whois is too short, and maybe disallowing it for ccTLDs only first may be an acceptable compromise.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 17, 2024 at 5:13 PM Andrew Ayer via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Ryan,<br>
<br>
We've seen evidence of two distinct security issues:<br>
<br>
1. CAs relying on an out-of-date database of WHOIS servers (original<br>
WatchTowr analysis).<br>
<br>
2. ccTLDs not maintaining an accurate record of their WHOIS server in<br>
the IANA Root Zone database (Hanno's analysis at [1]).<br>
<br>
We have not seen any evidence of issues with the WHOIS servers for<br>
gTLDs in IANA's database.  Indeed, all 17 examples of outdated WHOIS<br>
servers are for ccTLDs despite there being 4 times as many gTLDs as<br>
ccTLDs.<br>
<br>
I don't think it's reasonable to generalize to gTLDs based on ccTLDs,<br>
as ccTLDs aren't bound by any registry agreements and have historically<br>
been operated less competently than gTLDs.  For example:<br>
<br>
Outages of .io NS servers:<br>
<a href="https://hackernoon.com/stop-using-io-domain-names-for-production-traffic-b6aa17eeac20" rel="noreferrer" target="_blank">https://hackernoon.com/stop-using-io-domain-names-for-production-traffic-b6aa17eeac20</a><br>
<br>
Hijacking NS servers for .io:<br>
<a href="https://thehackerblog.com/the-io-error-taking-control-of-all-io-domains-with-a-targeted-registration/" rel="noreferrer" target="_blank">https://thehackerblog.com/the-io-error-taking-control-of-all-io-domains-with-a-targeted-registration/</a><br>
<br>
Hijacking NS servers for .cd:<br>
<a href="https://labs.detectify.com/writeups/how-i-hijacked-the-top-level-domain-of-a-sovereign-state/" rel="noreferrer" target="_blank">https://labs.detectify.com/writeups/how-i-hijacked-the-top-level-domain-of-a-sovereign-state/</a><br>
<br>
Registry compromise of .tg:<br>
<a href="https://groups.google.com/g/mozilla.dev.security.policy/c/4kj8Jeem0EU/m/GvqsgIzSAAAJ" rel="noreferrer" target="_blank">https://groups.google.com/g/mozilla.dev.security.policy/c/4kj8Jeem0EU/m/GvqsgIzSAAAJ</a><br>
<br>
The last three issues were security-critical and impacted DNS-based<br>
domain validation. It seems only the last issue was noticed by the<br>
WebPKI community, and the response was scoped only to .tg.<br>
<br>
A more targeted ballot would:<br>
<br>
1. Require CAs to perform WHOIS lookups by sending a query to IANA's<br>
WHOIS server and following the referral to the TLD's WHOIS server.<br>
Require CAs to perform RDAP lookups by using IANA's bootstrap file.<br>
Ban the use of HTTPS websites.  I believe this would give WHOIS/RDAP<br>
validation comparable security properties to DNS-based validation<br>
for gTLDs.  Note that the gTLD registry agreement places the same<br>
requirements on updating WHOIS/RDAP server information as it does on<br>
updating DNS server information.[2]<br>
<br>
2. Ban WHOIS/RDAP for ccTLDs.<br>
<br>
Regrettably, parsing emails sent to a Domain Contact is often the<br>
easiest way to implement automated validation for a large number of<br>
domains, since it allows delegation to a single central point, using<br>
configuration that is often already in place (WHOIS record contact<br>
information). Delegating DNS records using CNAME (e.g. with [3]) is<br>
better, but not as easy because it requires the subscriber to operate<br>
public-facing infrastructure.  So I think that banning WHOIS,<br>
particularly on this timeline, would lead to a net reduction in<br>
automation, and I don't believe this is justified by the available<br>
evidence when a more targeted fix is available.<br>
<br>
Regards,<br>
Andrew<br>
<br>
[1] <a href="https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20240913151529.2289f19d%40computer" rel="noreferrer" target="_blank">https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20240913151529.2289f19d%40computer</a><br>
<br>
[2] <a href="https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-21-01-2024-en.html" rel="noreferrer" target="_blank">https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-21-01-2024-en.html</a> "IANA Rootzone Database"<br>
<br>
[3] <a href="https://github.com/joohoi/acme-dns/" rel="noreferrer" target="_blank">https://github.com/joohoi/acme-dns/</a><br>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</blockquote></div>