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

[Amir Omidi]

While you are right about ACME not preventing MITM (and arguably, if we
could prevent MITMs then why even bother running CAs and WebPKI :P). I
think the framing on DNSSEC is actually pretty interesting.

While DNSSEC is not explicitly required (also, why? are there any
limitations on requiring DNS resolution to at least attempt DNSSEC?) I
don't think a CA would have a great time if they had a misissuance that
could've been prevented with DNSSEC. So at least, hopefully most large CAs
are already running with DNSSEC enabled. Beyond that, DNSSEC at least gives
some agency to the owner of a domain to help authenticate DNS records to an
extent.

Second, does the new multi-perspective domain validation stuff cover
anything beyond DNS and HTTP? If not, should it also explicitly cover all
validation methods (e.g., including phone calls and emails)?

Third, and this is a reference to a friend I have who works adjacent to the
domain business. But according to him, many registrars (mostly lesser known
and some larger registrars) don't allow you to modify DS records without
specifically reaching out to support (Something about the EPP process being
very loosely defined and non-standardized between different registries).

Given that these registrars are *often* responsible for (*partially)*
maintaining WHOIS data blob, the implication of the last point makes
relying on WHOIS information even a bit more "are we sure about that",
right? Effectively what I'm saying is that bringing WHOIS into the mix here
adds many more cooks to the kitchen, with considerably different cooking
skills.

There is not a well defined process for the responsibility of data returned
from WHOIS (the data && the protocol). What I'm not sure about is, does
RDAP solve this?

Also, on a side note I'm sad to see the DNSSEC adoption numbers have come
down :/ The timing is correlated with a certain large registrar shutting
down.

On Thu, Sep 19, 2024 at 12:36 PM Andrew Ayer via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> 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
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240919/7a105f49/attachment.html>