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

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

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 <[e-mail]> wrote:
> 
> 
>> On Jan 11, 2018, at 22:46, Matthew D. Hardeman <[e-mail]> 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