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

[Mike Shaver]

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

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


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


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

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


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

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