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

[Andrew Ayer]

Hi Mike,

The DNS, HTTP, and ALPN-based validation methods are all
unauthenticated and susceptible to MITM attacks during validation.

DNS: The BRs do not require DNSSEC for domain validation, but even if
they did, it would have little practical effect since fewer than 5%
of .com domains use DNSSEC, and this percentage is trending down:
https://www.verisign.com/en_US/company-information/verisign-labs/internet-security-tools/dnssec-scoreboard/index.xhtml

HTTP (both ACME and non-ACME methods): Using HTTPS is not required.
Validating certificate chains is not required when using HTTPS.

ALPN: validating the certificate chain is not required; in fact, the
presented certificate is an untrusted dummy certificate that's
just used to smuggle a token in an extension.

The DNS, HTTP, and ALPN methods all follow the same basic pattern: the
CA gives the Applicant a *public* token and the Applicant publishes the
token in a location that only someone with control over the domain
should be able to *modify*: in a DNS record, under /.well-known on port
80/443, or in a certificate served on port 443. The CA checks that the
token is in the right place.  If it is, the domain is validated.

An active attacker can apply for a certificate from a CA, get a token,
and execute a MITM attack to return the token when the CA checks for
it. For example: https://notes.valdikss.org.ru/jabber.ru-mitm/

(The email methods follow a slightly different pattern: the CA sends a
*private* token to a location that only someone with control over the
domain should be able to *read*, such as webmaster@ or the email address
in a WHOIS record.  If the Applicant can furnish the private token to
the CA, the domain is validated.  An active attacker can MITM the domain's
mail server to get the private token.)

This is why validation using unauthenticated WHOIS is inherently no
less secure than the other methods of validation.

I'm sure you'll find this unsatisfying, but there is a fundamental
chicken-and-egg problem here.  How do you authenticate a request for a
WebPKI certificate when WebPKI certificates are the mechanism that the
Internet uses for authentication?

The WebPKI has chosen to mitigate this fundamental problem using:

1. Certificate Transparency, so domain owners can detect unauthorized certificates.

2. Multi-perspective validation to make certain types of MITM attacks
harder.

Regards,
Andrew