<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" target="_blank">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"><u></u>
<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" target="_blank">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><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 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 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, 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! 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><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 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>Mike</div><div><br></div><div> <br></div></div></div>