[Servercert-wg] Transitive Trust and DCV (was Re: Ballot SC-080 V1)

[Mike Shaver]

Hi Dimitris,

I've been thinking about your email all night, and I want to figure out
where our reasoning about the integrity of DCV via WHOIS-1932 or HTTP-nonce
(3.2.2.5.1) diverge. I was quite surprised by your statements about the
properties of internet security, the responsibility of TLS and SCWG, and
the limitations that should be accepted in performing DCV. I'm hoping that
your new responsibilities as Chair (congratulations!) will still leave you
a bit of time to point out where my reasoning doesn't connect. :)

Because I'm not sure where we diverge, I'm going to walk through my
understanding of the principles underlying the DCV methods used
historically by CA/BF (and CAs in the dark days of private deals with
individual browsers), and the direction towards which the SCWG and root
programs seem to be headed in terms of those principles. Please, *please*
do not take this as me implying that you don't know these things: I'm not
trying to lecture, but to be as explicit as reasonable in explaining my
thinking, so that it's easiest for yourself or others to help me correct
error in it. I would be quite grateful for such generosity, honestly! I
also apologize in advance for the length of this message. I lack the wisdom
to make it smaller, perhaps.

(Some of this is entangled with "what is this even for?" sorts of
discussion about who the web PKI should ultimately benefit, but I've tried
to keep that separate.)

On Wed, Sep 18, 2024 at 12:18 PM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

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

A recurring theme throughout web PKI operations has been that a participant
in the ecosystem thinks that they are doing a good job, and perhaps indeed
are doing a good job of some kind, but are not providing the guarantees or
protections that others are assuming are in place. I don't mean "good job"
in the sense of competence or ethics, but rather "meeting the requirements
through actions". The farther that the participant is from the core of the
web PKI ecosystem, which is to say the less likely they are to evaluate all
their actions by the effects of those actions on the trustworthiness of web
certificates and server authentication. This means, IMO, that this group
and other stewards of the PKI should be very conservative, and very
explicit, when depending on another participant of the ecosystem to
maintain certain properties. Otherwise, those dependency-bearing
organizations may not even know what is being expected of them.

I am not suggesting that CA/BF in any way place requirements on what an
organization must do in order to be a domain registrar, and reporter of
that registry. As you say, that is beyond both the scope and the expertise
of this group, and this group has plenty to keep it busy! I am, rather,
suggesting that SCWG should establish criteria against which it will
determine if a registrar's publication of domain information should be
considered to be reliable enough to accomplish DCV. Similarly, the group
does not put any requirements forcing public DNS servers to strictly check
DNSSEC, but if a CA is going to use a DNS server for checking CAA records
or doing 3.2.2.4.7 "DNS Change" validation, then that's only acceptable if
the DNS server enforces DNSSEC in the presence of a validation chain. (I
think that might only be in Bugzilla and not yet captured in the BRs, but
it's well-enough understood that failure to adhere to it has required
reissuance.)

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 above, this depends very much on exactly what form "not functioning
properly" takes. If their systems are broken such that it's impossible to
make changes to registrations, or to look up registrations, I think we
would all agree that the TLD operator is not functioning properly, but that
would not have as much risk to the integrity of the web PKI as those
systems being broken such that *anyone* can change any TLD.

For CAs to rely on email address information from registrars for issuance
of certificates, I think it's only appropriate that they ensure that the
information is "fit for purpose" and that it's managed (and accessed) in a
way consistent with the level of trust placed in it.

This means making sure that the integrity of the response is maintained,
which is a role that WHOIS-3912 simply cannot perform.


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

DNS being unencrypted is not a problem, and indeed even DNSSEC doesn't
encrypt traffic. DNS results being *unauthenticated* is a problem for
clients who wish to be certain that they have been given an authorized
address in response to their lookup, but even with DNSSEC that leaves the
issue of ensuring that the unauthenticated IP layer reached the "real" home
of that address (thus DANE).


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

Again, encryption during validation is not necessary for there to be a
reliable chain of trust from the browser to the site certificate, via
CA-operated root certificates. We need authentication, but only
authentication, of every step of the delegation of trust.


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


This is a part that really got stuck in my head. Are you saying that ALPN-1
is vulnerable to a MITM attack during validation? That would be a pretty
shocking situation, in my opinion!

How would the attacker get access to the key material needed to complete
the challenge? It never leaves the subscriber machine from what I can tell.
Similarly, the ACME account key is used in HTTP-01 to render MITM attacks
ineffective.

This is how the trust in that connection is bootstrapped based on the trust
in the connection between subscriber and CA when the certificate is
requested. Presumably publicly-trusted certificates are used when the
subscriber connects to the CA's server to make that request and obtain the
account key!

This transitivity of trust goes to the issue with WHOIS. Even if the
registrar is maximally diligent in their key ceremonies and internal
processes and generating certificates correctly, WHOIS-3912 puts a
*maximum* trustworthiness on the entire operation, which is that of
unauthenticated TCP. In my opinion, that is not appropriate for web PKI,
and is a relic of a time before this community took technical
registration-time attacks as seriously as we do now.

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.

Could you describe how a non-problematic WHOIS-3912 library could provide
assurance of the validity of the data returned, equivalent to the integrity
of the results from HTTP-01/DNS-01/ALPN-01?

Instead, we could focus on requiring immediate/emergency measures for CAs
> to use the WHOIS protocol securely
>

This is definitely one place that our reasoning diverges: I don't see a way
to use WHOIS-3912 securely, where by "securely" I mean "in such a way as to
not weaken the DCV guarantees that the web PKI wishes to make".


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.

Why do CAs need to rely on unauthenticated communication to achieve that?
If we were establishing the very first root, someone would have to carry
the key physically to the browser developer as a form of IRL
authentication, but we have sufficient systems in place now to inductively
create a completely authenticated chain of validation if we should want to.

Where is that chain impossible to authenticate, in your opinion?

I'm confused by this statement. Is this a plea to the CAs to stop using
> what you think is an insecure method?


Yes, it is exactly that. I don't know how anyone can seriously claim that
WHOIS-3912 is a secure method, regardless of how high quality the data on
the other side is.

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


As above, domain registrars do not need to meet any SCWG requirements. CAs
need to meet the SCWG requirements, and I think that those requirements
should include minimum properties that must hold of a registrar's data
management practices, and the means of accessing it, if such data is to be
used as authoritative proof of domain control.

An example: do registrars inform registrants that anyone who can receive
email at the listed contact address can be issued a certificate for their
domain? I think that the significance of that address as used for DCV is
not well-understood by most registrants, and that many will send that email
to ticket/CS lists composed of people who are *not* authorized to make
changes to DNS, and are not assumed to have the same authority for
requesting certificates. Similarly, I don't think that registrants
understand that someone popping a domain-privacy provider not only gets
their email and contact information, but could plausibly also silently have
certificates issued against their domain.

If these participants in the ecosystem (registrar and registrants) don't
regard the email contact field as having such immense security
significance, then it is unlikely that they will manage it with appropriate
care. Given that, as you correctly point out, the SCWG is in no position to
put requirements on registrars or registrants, all that we can do is say
that CAs must not use registrar data unless it is managed to an appropriate
standard, and accessed in an appropriate way. That is *well* within the
mandate of the SCWG, and consistent with all of its other activities in
defining validation standards.


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

If CAs are going to continue to use WHOIS-3912, I think that the SCWG
should require that the traffic be carried over an authenticated TLS
channel, or that the response be signed. Anything less doesn't address the
fundamental insecurity of the *access protocol*, whatever the truth of the
data returned in the request. Do you feel that unauthenticated requests
over the public internet really have a place in DCV?

Saying that the internet is fundamentally insecure is like saying that
electricity is fundamentally insecure, to me. The base protocols of the
internet, like IP, don't provide sufficient security properties given the
importance of the modern web. But just as TCP provides in-order delivery
over un-ordered IP, and TLS provides privacy and integrity over TCP (which
features neither of those, save a trivial attempt at integrity aimed at
signalling errors and not malicious interception), the web PKI can provide
authentication of domain ownership and connection validity by layering
appropriate protocols (computer and human) atop the less-capable lower
layers. That to me is the essence of the mandate of the SCWG. We are to TLS
what ICANN is to DNS: ICANN doesn't say that you can't return arbitrary
nonsense in a DNS response from your server on a private network, but it
*does* say that if you want to operate a DNS server on behalf of a gTLD,
you need to meet certain requirements or ICANN simply won't point traffic
at you. We should "stop pointing traffic" at certificates that were
validated using WHOIS-3912 DCV, and I wish I'd pushed to do so multiple
decades ago.

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