On Fri, Jan 19, 2018 at 9:22 AM, Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> 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. > > I think many parties have made quite clear that the level of description in BR method #10 covers a lot of possibilities, but there is insufficient technical description in the method to call TLS-SNI-01. Indeed, it appears from discussions prior that BR method #10 was engineered to incorporate sufficient flexibility for TLS-SNI-01 as well as some other mechanisms. Part of the trouble is "on the Authorization Domain Name" doesn't mean anything specific. > > 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) I think reliance upon TLS-SNI-01 should cease in the general case. The cause for which it should be rejected is because reliance strictly upon TLS-SNI-01 is clearly demonstrated to yield a perverse consequence: issuance of certificates to parties other than those who should be able to receive them. However, there is simultaneously a quite reasonable argument that the TLS-SNI-01 method is fully compliant with BR method #10. This means the deficiency is in BR method #10, not strictly in TLS-SNI-01. I would submit that if complying with BR method #10 were the sole goal, TLS-SNI-01 achieved and continues to achieve that. And yet, clearly TLS-SNI-01 can not be used for trust in the real world. In fact, as now specified, BR method #10 can not be used for trust in the real world. As to any mechanism of implementing BR method #10 without reliance on SNI, there is an equally strong case to be made that not relying on SNI is getting you a different web context in many shared hosting environments than specifying the correct ADN in the SNI would. That, in turn, is equally capable of causing issuance to parties other than intended. You can not have it both ways. If method #10 is violated by sending the wrong SNI value, an equally good argument exists that sending no SNI value at all is also in violation. The fact of the matter is that method #10 specifies none of this, so it's all fair game. Because method #10 is a vacuous one-liner, there can be no reasonable support for compliance/non-compliance on a concept that method #10 does not even touch on. > > 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. > I concur that the evidence strongly suggests that the ACME working group did an insufficient job of researching and documenting realities in real-world deployment of website hosting environments, which is disingenuous for those building a protocol to secure the issuance of PKI certificates whose overwhelmingly prevalent use is the authentication and encryption of web site traffic. > > > 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. > This question seems rather inappropriate. By all appearances, TLS-SNI-01 is arguably compliant with BR method #10. If mitigations at partner hosting infrastructure are in place and functional, the issuance utilizing TLS-SNI-01 is secure for those parties. Let's not forget: the administration of ANY shared hosting infrastructure could successfully validate by any non-DNS method as they've been trusted by their clients to host their websites... If Let's Encrypt has worked with certain partners to ensure that there's not an unknown security risk allowing for TLS-SNI-01 to be abused by outsiders, where is the problem? > 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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
