<!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 18/9/2024 3:07 μ.μ., Mike Shaver
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CADQzZqvY2pKRP+6SazNiThd5HDdNbs+bm2jPMu4F=tiqwoUxRg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Hi Dimitris,<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Sep 17, 2024 at
2:55 AM Dimitris Zacharopoulos (HARICA) <<a
href="mailto:dzacharo@harica.gr" moz-do-not-send="true"
class="moz-txt-link-freetext">dzacharo@harica.gr</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">
<div> <br>
<br>
<br>
<div>On 16/9/2024 11:39 μ.μ., Mike Shaver wrote:<br>
</div>
<blockquote type="cite">
<div>
<div class="gmail_quote">
<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>
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"
moz-do-not-send="true">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>
</div>
</blockquote>
<div><br>
</div>
<div>Sorry, yes, I understand that they are monitored, but I
don't know exactly what's monitored. As an analogy, a CA
might have SOC2, which is a form of audit and valuable to
its customers, but that would not suffice for purposes of
them issuing certificates: they need to have the WebTrust
stuff audited as well. (I don't actually care if there's a
specifically-accredited audit stamp, my point is that IANA
might not be monitoring for the same things that SCWG would
expect to suffice for use as DCV.)<br>
</div>
</div>
</div>
</blockquote>
<br>
We don't need Domain Name Registrars to go through WebTrust or ETSI
audits suitable for Trust Service Providers. These Registrars are
the source of truth for the DNS on which all Internet connections,
and the WebPKI relies on. It's so fundamental to the ecosystem that
IMO it doesn't make sense to ask ourselves how this Forum can make
them better. Other authorities should be working on that.<br>
<br>
If a ".cookoo" TLD operator is not functioning properly, then the
entire TLD is in jeopardy and every Domain owner under that TLD is
at risk. Certificates are the least of people's problems when
relying parties connect to websites operated under that unsafe TLD
operator.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CADQzZqvY2pKRP+6SazNiThd5HDdNbs+bm2jPMu4F=tiqwoUxRg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<blockquote type="cite">
<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>
</div>
</blockquote>
<div><br>
</div>
<div>Well yes, which is sort of why the SCWG and TLS exist in
the first place! If you know of other DCV methods that are
similarly unprotected from DNS attacks, I very much think
that we should look critically at them as well!<br>
</div>
</div>
</div>
</blockquote>
<br>
No, the SCWG and TLS is not here to solve the unencrypted nature of
the DNS protocol. IETF and DNSSEC is. There is a great number of
Domain Names in the DNS without DNSSEC, and there is still heavy
reliance on the unencrypted DNS protocol in almost EVERY Domain
Validation under 3.2.2.4.<br>
<br>
Even the Agreed-upon change to website method, 3.2.2.4.18, relies on
"Authorized Ports that are offered via non-encrypted channels (ports
80, 25, 22).<br>
<br>
I would go as far as to say that even the ACME methods connecting to
https URLs are untrusted, because the endpoints are not protected by
publicly trusted certificates and anyone could launch a MiTM attack.<br>
<br>
<blockquote type="cite"
cite="mid:CADQzZqvY2pKRP+6SazNiThd5HDdNbs+bm2jPMu4F=tiqwoUxRg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>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.</div>
</blockquote>
<div><br>
</div>
<div>Could you elaborate on the proportionality here? From my
perspective, there is a publicly-demonstrated vulnerability
in DCV that can only be promptly remedied by ceasing use of
WHOIS-the-protocol (at least)<br>
</div>
</div>
</div>
</blockquote>
<br>
.com, .org, .net, .healthy-operators are operating just fine and the
Internet has been working reliably with Domain Names under those
reliable TLD operators.<br>
<br>
On the other hand, there might be some "unreliable" TLD operators
for which certificate issuance is the least of the Internet's
problem. For example, if we know that there is a rogue TLD operator
that may change the NS records of Base Domain Names under that TLD
at will in order to intercept traffic, the WebPKI ecosystem can do
nothing about it but to ask public CAs to block that TLD from
getting certificates. Fortunately, we have not seen such a case with
this security issue.<br>
<br>
In addition to that, in my previous email, I specifically focused on
the flaw of certain WHOIS libraries that fail to search for the
source-of-true regarding TLD Registrar entry points. In order for
the SCWG measures to be proportionate, we should not blame the
entire WHOIS protocol but work on additional controls to minimize
the risk of CAs using those problematic WHOIS libraries.<br>
<br>
<blockquote type="cite"
cite="mid:CADQzZqvY2pKRP+6SazNiThd5HDdNbs+bm2jPMu4F=tiqwoUxRg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> 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>
</div>
</blockquote>
<div><br>
</div>
<div>There are a few issues here:<br>
</div>
<div><br>
</div>
<div>WHOIS: The BRs currently make mention in multiple places
of WHOIS and specify WHOIS-the-protocol (RFC 3912).
WHOIS-the-protocol is clearly inappropriate because of it
being subject to DNS interception, </div>
</div>
</div>
</blockquote>
<br>
I disagree. We are trying to move from "http" to a "trustworthy
https" (note: "trustworthy https" in the sense that it doesn't use
untrusted certificates). At some point, CAs need to rely on
unencrypted communication to achieve that. The Forum and SCWG has
been working for years to make sure the Domain Validation methods
have reasonable controls to minimize the risk of a certificate being
issued to an entity that is not associated and does not control the
Domain Name in the certificate. Historically, the Forum has
deprecated methods that are proved to be insecure in their entirety
but I don't think this is one of those cases.<br>
<br>
<blockquote type="cite"
cite="mid:CADQzZqvY2pKRP+6SazNiThd5HDdNbs+bm2jPMu4F=tiqwoUxRg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>and I'm a little embarrassed that in my recent dives into
the BRs and validation methods I didn't twig to the fault
there. WHOIS the protocol should be sunset by CAs
*immediately*, IMO. They should all be following this list
and Bugzilla, and they should have all seen that if they're
using WHOIS-3912 they're issuing insecurely (independent of
takeover attacks! </div>
</div>
</div>
</blockquote>
<br>
Who is "they"? I believe CAs in this WG monitor m.d.s.p. and other
lists but some might not agree with your assessment that all Domain
Validation methods must rely on fully-encrypted communication
end-to-end. Certificates are trying to solve exactly that
fundamental problem, using the insecure Internet.<br>
<br>
Domain Names are also susceptible to takeover attacks. You can
search the web and find multiple sources and articles describing how
Domain owners lost control of their Domain Names. Digital
Certificates can't prevent these cases from happening.<br>
<br>
<blockquote type="cite"
cite="mid:CADQzZqvY2pKRP+6SazNiThd5HDdNbs+bm2jPMu4F=tiqwoUxRg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>the protocol itself is fatally flawed!), and they should
cease issuance using that method—without waiting for BR
revision to codify it. That's just good faith operation of a
certificate authority, given what is known and has been
demonstrated. If there is a CA that wants to make the
"critical infrastructure" argument about domain validation
by WHOIS-3912 then I'd be very curious to hear how emergency
validation through other mechanisms isn't possible.</div>
</div>
</div>
</blockquote>
<br>
I'm confused by this statement. Is this a plea to the CAs to stop
using what you think is an insecure method? Everyone is entitled to
an opinion but that's why we are having these discussions publicly
so that the SCWG members can find "substantial consensus" as
mandated in the Bylaws. I'm sure some CAs are already working, or
have already stopped using WHOIS, proactively, until this discussion
comes to an end.<br>
<br>
<blockquote type="cite"
cite="mid:CADQzZqvY2pKRP+6SazNiThd5HDdNbs+bm2jPMu4F=tiqwoUxRg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>RDAP: RDAP looks like it would give transport security
and a better ability for IANA to ensure the integrity of
domain-to-registrar mappings, which is certainly progress,
but:</div>
<div><br>
</div>
<div>Domain Registries for validation of domain contacts:
domain registry information should, IMO, only be used at
*all*, independent of protocol, if the SCWG can be confident
that IANA or another trusted body will be able to ensure
that all those registries, for all domains present and
future, will meet the SCWG's requirements for reliability.
This includes whatever the requirements might be for who can
alter the record, as well as the maximum latency for updates
to be available after the change of control of a domain—and
how those are <br>
</div>
</div>
</div>
</blockquote>
<br>
This is like saying that the Registrars, the main stewards assigned
to run the DNS which is fundamental for how the Internet works and
practically the World Wide Web, need to meet the SCWG requirements
for reliability. I think there is a very big misunderstanding on how
things work and I'm surprised we are having this discussion. It is a
dependency problem:<br>
<ul>
<li>The web needs certificates to run securely. </li>
<li>The web also needs DNS to run. </li>
<li>DNS entry points for all Base Domain Names are managed by
gTLD/ccTLD Registrars.</li>
</ul>
<p>Put differently, if CAs are managing "the keys to the Internet",
domain name Registrars are managing "the backbone of the
Internet". That's just how things work IMO and I'm already
wondering if I'm missing something huge or fundamental, and I'd
hope someone else can confirm this dependency issue or present why
this is not the case.<br>
</p>
<br>
<blockquote type="cite"
cite="mid:CADQzZqvY2pKRP+6SazNiThd5HDdNbs+bm2jPMu4F=tiqwoUxRg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> 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>
</div>
</blockquote>
<div><br>
</div>
<div>There is no possible secure implementation of
WHOIS-as-RFC-3912 without additional specification of an
authenticating transport layer. That's just
bytes-on-the-wire fact, and no grace period is going to
improve anyone's safety on the web.<br>
</div>
<div><br>
</div>
<div>(That a DCV method has been used unmodified for decades
is a sign that we should subject it to *more* scrutiny, not
less, IMO. I was there decades ago and while I'm generally
proud of the work done by this community before and after
CA/BF came to be, we were certainly much less sophisticated
in our understanding of the threat models for domain
validation and certificate abuse than we are today. MPIC,
for example, was not considered a meaningful issue at the
time, and we now know well that it represents a clear and
present threat to web PKI integrity. I probably should have
seen unencrypted-WHOIS as a bad choice, though. :( )</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<br>
There is no need to feel bad about this because, as stated earlier,
almost all validation methods approved by the BRs have some sort of
unencrypted communication in order to prove control of a Domain Name
with some reasonable assurance. MPIC is a great example of a
proportional measure, taken to mitigate a known-for-years threat
that affected a few Domain Names taken over by BGP hijacking
techniques, but which was not ever considered to be so wildly abused
in a way that would break the webPKI. I believe the WHOIS
deprecation could follow a similar pattern but for sure the SCWG
should urgently focus on requiring CAs to use WHOIS libraries that
query the proper Registrar endpoints, IF they are using the WHOIS
method to query Domain Contact information.<br>
<br>
Dimitris.<br>
</body>
</html>