On Wed, Jan 10, 2018 at 2:38 PM, Ryan Sleevi <r...@sleevi.com> wrote:
> > I think it's important to point out that these levels of technical > discussions are best directed to the IETF ACME WG, under the auspices of > the IETF NoteWell - https://datatracker.ietf.org/wg/acme/about/ > Noted. If you think there's potentially merit in the modifications I've rough sketched here, please indicate as much and I will consider attempting to pursue as directed. > > >> To the extent that this is true, I harbor significant concern that >> TLS-SNI-01 could responsibly return to use. >> >> I also see a possibility that the mitigations in TLS-SNI-02 may be >> ineffective in this case. TLS-SNI-02 would prevent naive and automatic >> accidental success of validations by some infrastructure, but an attacker >> who can still create the proper zone in .acme.invalid and upload a custom >> certificate to be served for this zone would still be able to succeed at >> validation. >> > > Can you explain what you mean by 'create a proper zone'? .invalid is an > explicitly reserved TLD. > I apologize. I realized almost immediately on posting that message that I had erred significantly in oversubscribing that word. My prior messages's "zone" would have been better written as "web hosting context", roughly defined as that embodiment of configuration and resources which would define a hosting architecture's responses to HTTP requests directed to the infrastructure with one of a number of configured-and-bound-to-the-web-hosting-context domain labels in the Host: header, and for TLS connections those TLS connections reaching the hosting infrastructure with a TLS SNI name of that same set of configured-and-bound-to-the-web-hosting-context domain labels. You correctly point out at .invalid is a reserved TLD. I imagine there are a great many hosting infrastructures which allow creating such a new web hosting context and then binding not-yet-used-elsewhere-on-this-infrastructure DNS labels prospectively, without any kind of actual DNS validation. More importantly, I need not imagine it. As Patrick Figel pointed out, it is confirmed that DirectAdmin, a software infrastructure for hosting with some not insignificant number of deployments appears to do just so. I imagine that Mr. Thayer can add more to the conversation regarding the reasons and level of market penetration and practice, but it does appear that many shared hosting infrastructures will allow creating new configurations without having yet pointed the matching real DNS entries to the infrastructure. There are pre-staging, development, testing, etc, etc, reasons that some of the customers out there seem to want that. Obviously, there are better ways to handle that, and yet... In so far as others have already found examples, it is a market reality, unless there is compelling evidence to the contrary. In the exact text above, what I meant by "create the proper zone in .acme.invalid" was to create that web hosting context (or actually set of web hosting contexts) and bind to the Host names that are the z(i)[0...32].z(i)[33...64].acme.invalid labels that the attacker knows to be the set of those which may arrive in the TLS SNI name values for the validation calls from the CA to the TLS infrastructure. I clarify again that I'm not speaking of any real DNS mapping at all. I'm speaking of a mapping between a received TLS SNI label to a web hosting context on the hosting infrastructure. > > >> However, even that plan only actually gains security if the hosting >> infrastructure would generally apply protection for heretofore unknown >> names which are children of existing boarded named on another customer's >> account. In other words, how likely is it that if I have a login at some >> hosting company, and I have boarded on my account a hosting zone that >> includes the labels www.example.com and example.com that a totally >> separate >> login would be allowed to prospectively create a zone called >> notreallyexample.example.com? If that's likely or even non-rare, there's >> still a problem with the mechanism. >> >> > It is likely and non-rare (infact, quite common as it turns out). There > are very few that match domain authorizations in some way. Note that this > is further 'difficult' because it would also require cloud providers be > aware of the tree-walking notion of authorization domain name. > > So I don't think this buys any improvement over the status quo, and > actually makes it considerably more complex and failure prone, due to the > cross-sectional lookups, versus the fact that .invalid is a reserved TLD. > If this is the case, I can only conclude that all presently proposed enhancements to TLS-SNI-01 and TLS-SNI-02 validation, including my own rough sketch recommendations, are deficient for improvement of security and all of these TLS-SNI validation mechanisms are materially less secure and less useful than the other ACME methods that Let's Encrypt presently implements. All the recommendations and guidance in the world is unlikely to timely change the various (and there are so many) hosting providers' behavior with regards to allowing creating of web hosting contexts for labels like "*.*.acme.invalid". The CAs are beholden to the CABforum and root programs. The various web hosts are not. That being the case, I would recommend that the proper change to the TLS-SNI-0X mechanisms at the IEFT level would be the hasty discontinuance of those mechanisms. As long as the web hosting infrastructure does not automatically create new contexts for heretofore never seen labels, it won't be possible to fully validate in an automated fashion whether or not a given hosting infrastructure would or would not allow any random customer to create some blah.blah.acme.invalid label and bind it to a certificate that said random customer controls. Because of the various incentives and motivations, it seems almost inevitable that it would eventually occur. When a mis-issuance arises resulting from that scenario, I wonder how the community would view that? Thanks, Matt Hardeman _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
