Hopefully the validation summit next week will lay out the assumptions on what needs to happen outside of the CAs’ control to properly perform domain validation. Accurate technical descriptions of what’s needed for successful domain validation will help evaluate each method and we’ll be able to more clearly evaluate the risk, and you’ve hit several important points in your email.
While methods 9 and 10 are still in the BRs, I’ve written them off because the root programs have mandated mitigations to permit their temporary continued use. It sounds like they may be updated to specify the mitigations, which is good – we need TLS based method. From: Ryan Sleevi [mailto:[email protected]] Sent: Monday, February 26, 2018 4:09 PM To: Doug Beattie <[email protected]> Cc: [email protected]; IETF ACME <[email protected]> Subject: Re: [Acme] ALPN based TLS challenge On Mon, Feb 26, 2018 at 3:33 PM, Doug Beattie <[email protected]<mailto:[email protected]>> wrote: I would find it a bit surprising if the CABF adopted a domain validation method that relied on the web hosting provider claiming to do the right thing (to separate users on shared IP addresses so they cannot request certs from the other customers on that IP address). I'm surprised that it's seen as surprising, as this is already the implicit assumption for the validation methods within the CA/Browser Forum's Baseline Requirements. Notable among the comparisons would be to 3.2.2.4.4, which makes a presumption that the email provider for the domain has not only observed RFC 2142 Section 5, but also the CA/Browser Forum specific aliases of "admin" and "administrator" Yes, that is true, but in this case the domain owner is protecting their domain. The potential abuse of method 10 or 6 when servers that permit multiple customers on one IP address don’t implement the proper mitigations would open up any domain on shared IP address to improper domain validation. The discussions and comparisons of each method would likely highlight this as a smaller risk and one that the domain owner can mitigate themselves. Alternatively, one might consider the comparison to 3.2.2.4.6, in which the presumption is made that the /.well-known/ path is restricted from general access. Section 8.3 of ACME ( https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-8.3 ) specifically encourages the following of redirects when dereferencing the /.well-known/, but this understandably opens up attacks should a blanket redirect be used. That said, I do think the artificial distinction between "web hosting provider" may be detrimental. Given the existing of the CA/Browser Forum's 3.2.2.4.8, one can equally see an attack made under such shared-hosting scenarios by any CA that utilizes the .8 methods of validation, in that multiple tenants on that IP would have access to respond for that IP (under 3.2.2.5) Agree, and you didn’t even bring up the “any other method” buried in .8 which is even worse. Has anyone discussed this with the CABF? I’d recommend that someone send this out to the public list for feedback. Considering that the method described is consistent with 3.2.2.4.10 in the Baseline Requirements, did you mean to suggest conversations with Root Store programs that might otherwise restrict the usage of methods beyond that of the Baseline Requirements, such as forbidding 3.2.2.4.1, .5, .9 and .10 without specific mitigations? Having a clear set of approved mitigations for these methods is necessary. If ALPN is to be listed as an approved method and the mitigations are clearly called out in method 10 (or a new method), then it will be clear to everyone how they can be used. Right now it’s not at all clear how 9 and 10 can be used, other than to propose mitigation to the root programs for review, and even when that is done, the approvals seem to be temporary (LE to phase out all use of TLS-SNI-01). Anyway, this is probably getting a bit off-topic for this list and we should bring it back to the CAB Public or Validation list where it belongs. As one such Root Store operator, we're happy to see this method progress within the IETF, and believe it provides suitable mitigations for the issues disclosed. In retrospect, the introduction of the TLS-SNI method as specified in https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-8.4 , is functionally no different than introducing a new e-mail alias in the 3.2.2.4.4 method of validation - that is, presuming that all at-risk domains (such as those that allow arbitrary e-mail registration) must now take steps to block. The proposed method provides an opt-in, rather than an opt-out, and thus provides suitable mitigation. Much like a domain holder could choose a hosting provider that permits arbitrary modification to /.well-known/ or arbitrary DNS modification, I do not believe this introduces any additional security holes compared to the presently-industry-accepted methods of validating domain control. Doug From: Acme [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Daniel McCarney Sent: Monday, February 26, 2018 2:14 PM Cc: IETF ACME <[email protected]<mailto:[email protected]>> Subject: Re: [Acme] ALPN based TLS challenge +1 The WG should adopt this document. I will volunteer to help review if adopted. On Mon, Feb 26, 2018 at 12:02 PM, Richard Barnes <[email protected]<mailto:[email protected]>> wrote: +1 This approach is a major improvement from earlier efforts at a TLS-based challenge. It follows normal TLS processing logic much more closely, differing only in the fact that the certificate presented has an extra extension. Minimizing the differences w.r.t. normal behavior seems like a good approach to avoiding the sorts of corner cases that have tripped up earlier flavors of TLS-based challenges. Before this is finalized as an RFC, we should verify empirically that most hosting providers will be secure in the presence of this challenge. But I'm convinced that the approach in Roland's document is likely enough to work that we should go ahead and develop a specification, which we can test as it matures. --Richard On Fri, Feb 23, 2018 at 11:41 AM, Stephen Farrell <[email protected]<mailto:[email protected]>> wrote: On 23/02/18 16:31, Salz, Rich wrote: > >> Here is the ID: >> https://datatracker.ietf.org/doc/draft-shoemaker-acme-tls-alpn/ > > Should the WG adopt this document? Yes. Having a sufficiently secure mechanism that works on port 443 is a good thing in general. I'm not sure how many folks were using tls-sni-01 for new domains (I was) but whatever that number was, is I think evidence that a port 443 scheme fills a read need. I assume that if problems are found with the new mechanism (whether those be technical, due to odd deployments or I guess even cabforum politics;-) then we'd recognise that and stop the work. The fact that we did that to tls-sni-02 hould be re-assuring wrt this. If one accepts the two assertions above then adoption seems like a no-brainer. S. > Speak up now, we'll make a > consensus decision next week. Also if you are able to help work on > it. If adopted, I would expect this to be on the agenda for London > next month, even if it's just to briefly introduce it. > > > _______________________________________________ Acme mailing list > [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/acme > -- PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) _______________________________________________ Acme mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
