The following discussion is only a sketched out idea and thus does not classify all the 10 blessed methods:
One rule that could reasonably be added to the BR or Mozilla requirements for the various methods could be this general safety rule: - Validation methods that check control over a single address (such as certificate responses, well-known URLs etc.) are only valid for the single name validated, not as proof of domain control. Thus they cannot be used to validate control of an entire DNS zone, and thus is not sufficient for preauthorizing certs for subdomains, nor for getting wildcard certificates. So for example, TLS-SNI-01 at best validates control of the requested DNS name, possibly only of the used acme.invalid name. In contrast the GlobalSign certificate method (as summarized in previous posts here, I have not validated their exact procedures) apparently validates the response for a specific name as both A/AAAA recond and SNI name, and then takes this as proof of only that single name. (There was some talk of wildcard use, which would not be OK under the stricter rule above). Examples of automatic validation methods good enough for proving full zone control, as needed for wildcard certs or preauthorizing further issuance would be DNS control over the zone apex, being the registrant listed in whois or receiving e-mails for [email protected]. For e-mail certificates (no current BR rules, only root program specific rules), ability to receive emails for [email protected] validates (at class 1 level) control of that one e-mail address. While control of [email protected] or [email protected] or the DNS for example.com validates (at class 1 level) control of all @example.com e-mail addresses unless example.com is on the e-mail equivalent of a public-suffix list. (Thus [email protected] can't get certificates for all the users without directly violating the sanctity of the e-mail accounts). On 19/01/2018 16:22, Doug Beattie wrote:
I think we’ve gotten off track. While the general discussion is good and we need to update the validation methods to provide more precise details, I want to get back to the point in hand which is asking if the ACME TLS-SNO-01 method is compliant with method 10. If method 10 specified that you could validate the random number at the same IP address as the SAN being validated, then it would have said that. How does validating the “Random Value within a Certificate on the IP address of the Authorization Domain Name” comply with validating the “Random Value within a Certificate on the Authorization Domain Name”? The TLS-SNI method specifically directs the CA to check for the random number on a location other than the ADN. Many CA’s haven’t complied with the Mozilla requirement to list the methods they use (including Google btw), so it’s hard to tell which CAs are using method 10. Of the CA CPSs I checked, only Symantec has method 10 listed, and with the DigiCert acquisition, it’s not clear if that CPS is still active. We should find out on January 31st who else uses it. In the meantime, we should ban anyone from using TLS-SNI as a non-compliant implementation, even outside shared hosting environments. There could well be other implementations that comply with method 10, so I’m not suggesting we remove that from the BRs yet (those that don’t allow SNI when validating the presence of the random number within the certificate of a TLS handshake are better). Regarding the comment on the ACME protocol: “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.” Yes, open review of the protocol was good. As you are likely aware, the specification points out [1] vulnerabilities with the use of ACME by hosting providers “The use of hosting providers is a particular risk for ACME validation.” It appears that the detailed analysis into these risks wasn’t performed or considered prior to using ACME. If the analysis was done the risk mitigation wasn’t documented in spec. Lastly, are any of the Platinum Let’s Encrypt sponsors (Mozilla, Akamai, Cisco, EFF, OVH and Chrome) using TLS-SNI-01? I only call them out because as large financial supports, they may be more incentivized to use it than others. Personally, I think the use of TLS-SNI-01 should be banned immediately, globally (not just by Let’s Encrypt), but without knowing which CAs use it, it’s difficult to enforce. [1] https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-10.2 From: Ryan Sleevi [mailto:[email protected]] Sent: Thursday, January 18, 2018 7:25 PM To: Doug Beattie <[email protected]> Cc: Alex Gaynor <[email protected]>; [email protected] Subject: Re: TLS-SNI-01 and compliance with BRs 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]<mailto:[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]<mailto:[email protected]>] Sent: Thursday, January 18, 2018 3:47 PM To: Doug Beattie <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[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:[email protected]><mailto:[email protected]<mailto:[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
Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
