<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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)?</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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).</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Given that these registrars are <i>often</i> responsible for (<i>partially)</i> 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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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?<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 19, 2024 at 12:36 PM Andrew Ayer via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Mike,<br>
<br>
The DNS, HTTP, and ALPN-based validation methods are all<br>
unauthenticated and susceptible to MITM attacks during validation.<br>
<br>
DNS: The BRs do not require DNSSEC for domain validation, but even if<br>
they did, it would have little practical effect since fewer than 5%<br>
of .com domains use DNSSEC, and this percentage is trending down:<br>
<a href="https://www.verisign.com/en_US/company-information/verisign-labs/internet-security-tools/dnssec-scoreboard/index.xhtml" rel="noreferrer" target="_blank">https://www.verisign.com/en_US/company-information/verisign-labs/internet-security-tools/dnssec-scoreboard/index.xhtml</a><br>
<br>
HTTP (both ACME and non-ACME methods): Using HTTPS is not required.<br>
Validating certificate chains is not required when using HTTPS.<br>
<br>
ALPN: validating the certificate chain is not required; in fact, the<br>
presented certificate is an untrusted dummy certificate that's<br>
just used to smuggle a token in an extension.<br>
<br>
The DNS, HTTP, and ALPN methods all follow the same basic pattern: the<br>
CA gives the Applicant a *public* token and the Applicant publishes the<br>
token in a location that only someone with control over the domain<br>
should be able to *modify*: in a DNS record, under /.well-known on port<br>
80/443, or in a certificate served on port 443. The CA checks that the<br>
token is in the right place.  If it is, the domain is validated.<br>
<br>
An active attacker can apply for a certificate from a CA, get a token,<br>
and execute a MITM attack to return the token when the CA checks for<br>
it. For example: <a href="https://notes.valdikss.org.ru/jabber.ru-mitm/" rel="noreferrer" target="_blank">https://notes.valdikss.org.ru/jabber.ru-mitm/</a><br>
<br>
(The email methods follow a slightly different pattern: the CA sends a<br>
*private* token to a location that only someone with control over the<br>
domain should be able to *read*, such as webmaster@ or the email address<br>
in a WHOIS record.  If the Applicant can furnish the private token to<br>
the CA, the domain is validated.  An active attacker can MITM the domain's<br>
mail server to get the private token.)<br>
<br>
This is why validation using unauthenticated WHOIS is inherently no<br>
less secure than the other methods of validation.<br>
<br>
I'm sure you'll find this unsatisfying, but there is a fundamental<br>
chicken-and-egg problem here.  How do you authenticate a request for a<br>
WebPKI certificate when WebPKI certificates are the mechanism that the<br>
Internet uses for authentication?<br>
<br>
The WebPKI has chosen to mitigate this fundamental problem using:<br>
<br>
1. Certificate Transparency, so domain owners can detect unauthorized certificates.<br>
<br>
2. Multi-perspective validation to make certain types of MITM attacks<br>
harder.<br>
<br>
Regards,<br>
Andrew<br>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</blockquote></div>