On Fri, Jan 19, 2018 at 10:22 AM, Doug Beattie <doug.beat...@globalsign.com> 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. > I find your faith in the CA/Browser Forum's technical ability disturbing, given the evidence. I don't think it's off track to point out that it's the same level of assurance as .6, .8, and .9. > 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. > No, that's not correct. You're attempting to define a usage of the protocol (TLS) that is not actually mandatory, in order to support the objection - yet as pointed out, neither the BRs nor the relevant specification (TLS) support that reading, nor do the other methods. > 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). > Your analysis is flawed, ergo your conclusions are derived from flawed reasoning. > > > 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. > While your reasons are incorrect on multiple technical dimensions, you are correct that we want to see an immediate cessation of _any_ use of the .9 and .10 methods, and then evaluate on a case by case basis the mitigating factors and risks that may necessitate a gradual phase out on a per-CA basis. > > > [1] https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-10.2 > > > > > > *From:* Ryan Sleevi [mailto:r...@sleevi.com] > *Sent:* Thursday, January 18, 2018 7:25 PM > *To:* Doug Beattie <doug.beat...@globalsign.com> > *Cc:* Alex Gaynor <agay...@mozilla.com>; mozilla-dev-security-policy@ > lists.mozilla.org > > *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 < > dev-security-policy@lists.mozilla.org> 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:agay...@mozilla.com] > Sent: Thursday, January 18, 2018 3:47 PM > To: Doug Beattie <doug.beat...@globalsign.com> > Cc: mozilla-dev-security-pol...@lists.mozilla.org > 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 < > dev-security-policy@lists.mozilla.org<mailto:dev- > security-pol...@lists.mozilla.org>> 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 > dev-security-policy@lists.mozilla.org<mailto:dev- > security-pol...@lists.mozilla.org> > > https://lists.mozilla.org/listinfo/dev-security-policy > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
