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

[Dimitris Zacharopoulos (HARICA)]

On 16/9/2024 11:39 μ.μ., Mike Shaver wrote:
> Hi Dimitris,
>
> On Mon, Sep 16, 2024 at 2:07 PM Dimitris Zacharopoulos (HARICA) via 
> Servercert-wg <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?

Hi Mike,

I recall past discussions at the Forum where this conversation between 
the quality of ccTLD vs gTLD operators took was covered in more detail 
but a more recent post 
<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20240913151529.2289f19d%40computer>in 
m.d.s.p. confirmed that gTLD operators are more closely monitored by 
IANA compared to the general case of ccTLDs. Of course, ccTLD operators 
in the EU are functioning under European Law (Regulations/Directives), 
and they are considered part of the Essential/Critical Infrastructure 
under the NIS2 Directive.

> 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.

Such an attack could be run, in theory, against any Domain Name that is 
not protected by DNSSEC. It is not specific to the WHOIS protocol.

>
> 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.

I must admit I didn't do much research for the .mobi TLD or the other 
TLDs reported in m.d.s.p 
<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20240912102457.0d87c028%40computer>. 
so my comment about this being a "vanity" TLD is incorrect.

I recall a case where a TLD registrar was involved in a security 
incident which allowed a number of takeover attacks (I did a quick 
search but couldn't find a reference, I need to dig harder). The 
community's reaction was to identify issued certificates in a particular 
period-of-time where the incident took place, CAs to revoke or 
re-validate those certificates (it's way back and I don't remember all 
the details), but not to ban the use of registrars, or to consider all 
registrars, insecure. At the end of the day, these are the entities 
responsible for managing the DNS of Domain Names for which CAs issue 
certificates for. They are by virtue trustworthy entities in the ecosystem.

If I understand correctly, the threat model indicates that the 
vulnerability is within WHOIS libraries that use stale or hard-coded 
entry-points for certain TLDs. CAs that use code directly querying IANA 
servers and following referrals, are safe. Is my understanding correct 
on this issue?

Just to repeat my previous statement, I support the deprecation of using 
the WHOIS protocol (RFC 3912) to retrieve Domain Registrant contact 
information but I am not entirely convinced about the expedited manner 
of removing it in its entirety. It seems disproportionate. Instead, we 
could focus on requiring immediate/emergency measures for CAs to use the 
WHOIS protocol securely, thus mitigating the immediate risk, and use a 
transition period that will allow CAs to gracefully migrate off the 
WHOIS and into RDAP. At the same time, if CAs want to completely 
discontinue WHOIS/RDAP, it would give time to their Subscribers to 
switch to other Domain Validation methods.

I don't have strong feelings about this but I'm afraid of this setting a 
bad precedence (killing a Domain Validation method used for decades 
because of bad/insecure *implementation* of this method).

Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240917/8bf1f44a/attachment.html>