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

[Maria Merkel]

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:
https://www.icann.org/en/system/files/files/presentation-slam-13may17-en.pdf

In most of these takeover situations, I would assume the Whois server was
first offline for an extended period of time.

I also think the timeline for disallowing Whois is too short, and maybe
disallowing it for ccTLDs only first may be an acceptable compromise.

On Tue, Sep 17, 2024 at 5:13 PM Andrew Ayer via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Hi Ryan,
>
> We've seen evidence of two distinct security issues:
>
> 1. CAs relying on an out-of-date database of WHOIS servers (original
> WatchTowr analysis).
>
> 2. ccTLDs not maintaining an accurate record of their WHOIS server in
> the IANA Root Zone database (Hanno's analysis at [1]).
>
> We have not seen any evidence of issues with the WHOIS servers for
> gTLDs in IANA's database.  Indeed, all 17 examples of outdated WHOIS
> servers are for ccTLDs despite there being 4 times as many gTLDs as
> ccTLDs.
>
> I don't think it's reasonable to generalize to gTLDs based on ccTLDs,
> as ccTLDs aren't bound by any registry agreements and have historically
> been operated less competently than gTLDs.  For example:
>
> Outages of .io NS servers:
>
> https://hackernoon.com/stop-using-io-domain-names-for-production-traffic-b6aa17eeac20
>
> Hijacking NS servers for .io:
>
> https://thehackerblog.com/the-io-error-taking-control-of-all-io-domains-with-a-targeted-registration/
>
> Hijacking NS servers for .cd:
>
> https://labs.detectify.com/writeups/how-i-hijacked-the-top-level-domain-of-a-sovereign-state/
>
> Registry compromise of .tg:
>
> https://groups.google.com/g/mozilla.dev.security.policy/c/4kj8Jeem0EU/m/GvqsgIzSAAAJ
>
> The last three issues were security-critical and impacted DNS-based
> domain validation. It seems only the last issue was noticed by the
> WebPKI community, and the response was scoped only to .tg.
>
> A more targeted ballot would:
>
> 1. Require CAs to perform WHOIS lookups by sending a query to IANA's
> WHOIS server and following the referral to the TLD's WHOIS server.
> Require CAs to perform RDAP lookups by using IANA's bootstrap file.
> Ban the use of HTTPS websites.  I believe this would give WHOIS/RDAP
> validation comparable security properties to DNS-based validation
> for gTLDs.  Note that the gTLD registry agreement places the same
> requirements on updating WHOIS/RDAP server information as it does on
> updating DNS server information.[2]
>
> 2. Ban WHOIS/RDAP for ccTLDs.
>
> Regrettably, parsing emails sent to a Domain Contact is often the
> easiest way to implement automated validation for a large number of
> domains, since it allows delegation to a single central point, using
> configuration that is often already in place (WHOIS record contact
> information). Delegating DNS records using CNAME (e.g. with [3]) is
> better, but not as easy because it requires the subscriber to operate
> public-facing infrastructure.  So I think that banning WHOIS,
> particularly on this timeline, would lead to a net reduction in
> automation, and I don't believe this is justified by the available
> evidence when a more targeted fix is available.
>
> Regards,
> Andrew
>
> [1]
> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20240913151529.2289f19d%40computer
>
> [2]
> https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-21-01-2024-en.html
> "IANA Rootzone Database"
>
> [3] https://github.com/joohoi/acme-dns/
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240917/ae3f0851/attachment.html>