<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 16/9/2024 11:39 μ.μ., Mike Shaver
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CADQzZqvCHQ1QDudgANHv9fos7wdMEXD8n5-352qJg6M8qW_T_Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">Hi Dimitris,</div>
<div dir="auto"><br>
</div>
<div dir="auto">On Mon, Sep 16, 2024 at 2:07 PM Dimitris
Zacharopoulos (HARICA) via Servercert-wg <<a
href="mailto:servercert-wg@cabforum.org"
moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>>
wrote:</div>
<div>
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
<div> Is there feedback about the number of TLDs and
possible certificate volumes that might be affected by
this attack?<br>
<br>
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.</div>
</blockquote>
<div dir="auto"><br>
</div>
<div dir="auto">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? </div>
</div>
</div>
</blockquote>
<br>
Hi Mike,<br>
<br>
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 <a
href="https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20240913151529.2289f19d%40computer">post
</a>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.<br>
<br>
<blockquote type="cite"
cite="mid:CADQzZqvCHQ1QDudgANHv9fos7wdMEXD8n5-352qJg6M8qW_T_Q@mail.gmail.com">
<div>
<div class="gmail_quote">
<div dir="auto">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.</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:CADQzZqvCHQ1QDudgANHv9fos7wdMEXD8n5-352qJg6M8qW_T_Q@mail.gmail.com">
<div>
<div class="gmail_quote">
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto"><br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
<div dir="auto">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)?</div>
</blockquote>
<div dir="auto"><br>
</div>
<div dir="auto">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).</div>
<div dir="auto"><br>
</div>
<div dir="auto">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?</div>
<div dir="auto"><br>
</div>
<div dir="auto">That plea for domain equality aside, I think
describing .mobi as a “vanity” domain is ahistorical, given
its origins and two-decade history. “<a
href="http://amazon.mobi" moz-do-not-send="true">amazon.mobi</a>”
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 <a href="http://google.mobi" moz-do-not-send="true">google.mobi</a>
didn’t exist except when the service was under the security
researchers’ control.</div>
</div>
</div>
</blockquote>
<br>
I must admit I didn't do much research for the .mobi TLD or the
other TLDs reported in <a
href="https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20240912102457.0d87c028%40computer">m.d.s.p</a>.
so my comment about this being a "vanity" TLD is incorrect. <br>
<br>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
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 <b>implementation</b> of this
method).<br>
<br>
Dimitris.<br>
</body>
</html>