Re: [Acme] Fixing the TLS-SNI challenge type

["Matthew D. Hardeman" <[e-mail]>]

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.