Upon reflection, I concur that the risk I was concerned about would be properly hedged against by the mere combination of using the domain label being validated in the SNI name coupled with the “acme” ALPN signal.
> On Jan 12, 2018, at 8:26 AM, Jonathan Rudenberg <[email protected]> wrote: > > >> On Jan 11, 2018, at 22:46, Matthew D. Hardeman <[email protected]> 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. > > I don’t believe this is true. I’ve already established that there are no > common TLS servers that blindly repeat back ALPN protocols, and this is > expected because RFC 7301 does not allow it: > https://tools.ietf.org/html/rfc7301#section-3.2 > >> 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. > > This would be a vulnerability in the hosting provider, not in ACME or any > ACME CA, in the same way that we wouldn’t blame the CA if a DNS provider > allowed anyone to write _acme-challenge TXT records. > > The reason why TLS-SNI-01/02 are in the process of being removed is a bit > different, the widespread vulnerability in the shared hosting providers > existed _before_ ACME, and so it makes sense to work around it to avoid > unnecessarily putting users at risk. This is not the case for the proposed > new method. > >> 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. > > This is where we are headed, I’ll be posting a new TLS-ALPN proposal today > based on the feedback from Roland. > >> 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. > > It’s important that the account key is not required to be online for > authorization, as it allows separation of privilege, the account key can be > kept safely away from publicly exposed frontend servers. A random token is > sufficient, I’m not aware of any reason why requiring the account key to be > online would improve security. > > Jonathan _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
