I strongly support the ideas that Martin Thompson is presenting on this matter. While this is a major change, it provides an opportunity build a mechanism to achieve the actual security goal: to ensure that the TLS endpoint that you’re speaking to when you follow all the routing steps a real browser would for a given endpoint successfully negotiates, within this new protocol, proof of possession of the validation challenge token along with confirmation, possession of the account key, and confirmation of what actual DNS label is being validated.
> On Jan 11, 2018, at 9:46 PM, Matthew D. Hardeman <mharde...@ipifony.com> > wrote: > > Hi, guys, > > I’m entirely new to this list and not sure whether or not I’m welcome, but I > have some comments on the ALPN idea. > > In order to actually be an improvement in security, the ALPN needs to be more > than a mere marker of support. > > Consider: The new mechanism is implemented and Let’s Encrypt deploys. > > Customer’s of not-secure-shared-webhost-A complain that they can’t get > validations via this easy mechanism. (The complaint would actually likely > originate internally by their own development staff.) > > Rather than do the work to ALSO fix the insecure aspects of the > infrastructure, they’ll hastily patch in the “acme" name. > > To add security, perhaps the SNI that is sent should be the actual domain > label that is being validated, along with the “acme” ALPN name. At this > point, an actual ALPN extension should negotiate the authentication, with the > server having the opportunity to bind the proper target name to a desired > authentication and then if and only if the server has available the account > key credentials of the requestor, would it be able to answer with a proper > authentication. > > Just adding a marker with the hammer being that just doing this without > implementing the promises that are supposed to be implied on pain of > violating an RFC is… Likely to get laughed at in a derisive way by the very > web hosts whose behavior now has you contemplating improvements to the > protocol. > > There’s no fast way out of this mess. > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
