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

[Dimitris Zacharopoulos (HARICA)]

On 18/9/2024 3:07 μ.μ., Mike Shaver wrote:
> Hi Dimitris,
>
> On Tue, Sep 17, 2024 at 2:55 AM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr> wrote:
>
>
>
>
>     On 16/9/2024 11:39 μ.μ., Mike Shaver wrote:
>>     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?
>     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.
>
>
> 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.)

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.

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.


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

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.

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

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.

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

.com, .org, .net, .healthy-operators are operating just fine and the 
Internet has been working reliably with Domain Names under those 
reliable TLD operators.

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.

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.

>     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.
>
>
> There are a few issues here:
>
> 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,

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.

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

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.

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.

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

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.

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

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:

  * The web needs certificates to run securely.
  * The web also needs DNS to run.
  * DNS entry points for all Base Domain Names are managed by gTLD/ccTLD
    Registrars.

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.


>     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).
>
>
> 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.
>
> (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. :( )
>

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.

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