I think others have already responded, but I do want to highlight one other problem with the reasoning being offered here: SNI is not mandatory in TLS. It's an extension (RFC 6066) that is optional.
More concretely, Methods .6, .8, .9, and .10 are all effectively demonstrations over the IP address pointed to by a domain - rather than the domain itself. I mention .6 in there because there is, for example, no requirement to use a "Host" header - you could use HTTP/1.0 (as some CAs, I'm told, do). Similarly, one can read that .10 doesn't actually require the TLS handshake to complete, nor for a ServerKeyExchange to be in any way related to the Certificate. It is, for example, sufficient merely to send a Client Hello and Server Hello+Certificate and terminate the connection. This is the challenge of defining validation methods in the abstract, rather than with concrete specifications. The ACME specification is useful in it's the first attempt I'm aware of that attempts to fully, normatively specify how to validate assurances in an open and interoperable way. The historic ambiguities derived from the BRs, working in abstract, technology-neutral ways, necessarily leads to these sorts of contrived scenarios. For example, .7 doesn't demonstrate control over an ADN - in as much as it allows control over a subdomain of an ADN to be treated as control over the ADN itself (if it has a leading prefix). .9 doesn't require the domain name appear within the Test Certificate - similar to the point being raised here about the domain name not appearing within the TLS handshake for .10. On Thu, Jan 18, 2018 at 4:46 PM, Doug Beattie via dev-security-policy < [email protected]> wrote: > The point is, you don’t really connect to the Certificate on the > Authorization Domain Name, you connect to a certificate on the same IP > address as the ADN, but you actually intentionally ask for a different > server name, which has no relationship to the ADN (except they happen to > share the same IP address). It seems like misissuance to me. > > > From: Alex Gaynor [mailto:[email protected]] > Sent: Thursday, January 18, 2018 3:47 PM > To: Doug Beattie <[email protected]> > Cc: [email protected] > Subject: Re: TLS-SNI-01 and compliance with BRs > > I guess it depends how you define "Certificate on the ADN" -- TLS-SNI-01 > performs a DNS lookup for the ADN, connects to that IP, and initiatives a > TLS connection with the .acme.invalid SNI value. > > Certificates don't exist on Domain Names if we think really hard about it, > but servers with IPs that domain names point to can serve certificates, and > that seems like a reasonable interpretation of the intent of that sentence, > which TLS-SNI-01 fulfills. > > Alex > > On Thu, Jan 18, 2018 at 3:43 PM, Doug Beattie via dev-security-policy < > [email protected]<mailto:dev- > [email protected]>> wrote: > Now that I'm more familiar with method 9 and 10 domain validation methods > and heard a few side discussions about the topic, it's made me (and others) > wonder if the ACME TLS-SNI-01 is compliant with BR Method 10. > > The BRs say: > 3.2.2.4.10. TLS Using a Random Number > Confirming the Applicant's control over the FQDN by confirming the > presence of a Random Value within a Certificate on the Authorization Domain > Name which is accessible by the CA via TLS over an Authorized Port. > > But it's my understanding that the CA validates the presence of the random > number on "random.acme.invalid" and not on the ADN specifically. Is the > validation done by confirming the presence of a random number within the > certificate on the ADN, or some other location? I'm probably misreading > the ACME spec, but is sure seems like the validation is not being done on > the ADN. > > Doug > > _______________________________________________ > dev-security-policy mailing list > [email protected]<mailto:dev- > [email protected]> > https://lists.mozilla.org/listinfo/dev-security-policy > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
