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

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Wed Sep 18 17:03:29 UTC 2024




On 18/9/2024 5:40 μ.μ., Tobias S. Josefowitz wrote:
> Hi Dimitris,
>
> On Mon, 16 Sep 2024, Dimitris Zacharopoulos (HARICA) via Servercert-wg 
> 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.
>>
>> 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 may have missed something, and if so, I am very open to input on that.
>
> That said, as the issue presents to me, it seems to illustrates that 
> multiple CAs must have been querying WHOIS servers which's hostnames 
> and domains simply do not exist anymore, for longer than just a brief 
> period, The possibility for this to occur without anyone noticing and 
> sounding the alarm to the WebPKI community alone seems to disqualify 
> WHOIS based Domain Validation as an acceptable method; this seemingly 
> inherent lack of monitoring into validations/validation attempts 
> performed via this method seems reason enough to retire it. And soon. 
> What else have we missed, if we missed this?

Are you claiming that some TLDs or Domain Names are defunct? I'm sure 
this is true in many cases. However, the majority of the TLDs work as 
expected. If a TLD is defunct (i.e. not accessible), why should the 
WebPKI community raise an alarm? Nobody can use that TLD reliably in the 
WWW anyway.

I would expect the WebPKI community to raise an alarm if they detect 
there is a malicious TLD operator or Registrar that has been compromised 
like it happened with .tg 
<https://groups.google.com/g/mozilla.dev.security.policy/c/4kj8Jeem0EU/m/GvqsgIzSAAAJ> 
(thank you Andrew, that's exactly the case I recalled and couldn't find 
references!), because that puts relying parties expected an encrypted 
interaction with those Domain Names in jeopardy.

>
> If this were the only problem with this validation method, it might be 
> merited to find ways to address this very fundamental issue with it, 
> try to compensate for it and adding safeguards around it. While the 
> BRs may not specifically mandate them, what would be required, 
> ignoring the issue of outdated but published WHOIS endpoints attackers 
> can get control of easily, to securely perform WHOIS based DV to begin 
> with, is a whole host of safeguards and compensations.
>
> In light of that, this current, fundamental issue really is our sign 
> to get rid of it.
>
> Tobi
>
> PS: While I wrote the above primarily thinking about WHOIS (the 
> protocol), I do not think that "scraping WHOIS data from a website" 
> necessarily sounds super robust either...

Securing the Internet needs to rely on some fundamental properties of 
the Internet, and one of those is the the fact that the Internet is 
fundamentally insecure and unencrypted. There is no way around that.

IMO, as long as DNS relies on Registrars and Registrars offer Registrant 
information with widely-acceptable protocols, they should be considered 
a good "starting point" for evaluation in a Domain Validation method. I 
would consider scrapping WHOIS information data from a secure website 
operated by the Registrar significantly more reliable than obtaining 
this information via an unreliable and unencrypted WHOIS query :)

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


More information about the Servercert-wg mailing list