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

From: "Matthew D. Hardeman" <[email-masked]>
Date: Thu, 11 Jan 2018 21:46:28 -0600

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.

---

From: "Matthew D. Hardeman" <[email-masked]>
Date: Thu, 11 Jan 2018 22:00:00 -0600

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 <[email-masked]> wrote:
> 
> Hi, guys,
> 
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 12 Jan 2018 15:20:08 +0200

On Thu, Jan 11, 2018 at 09:46:28PM -0600, Matthew D. Hardeman wrote:
> 
> In order to actually be an improvement in security, the ALPN needs
> to be more than a mere marker of support.
> 
> 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.
> 

The mechanism is presumably bound by "method 10" from current CABForum
BRs.

The language in the BRs is (paraphrased):

'A random value in a certificate on the name being validated'.

So the certificate must contain both the name being validated and the
random value.

That certificate may be either X.509 certificate (which are apparently
a bit nontrivial to generate, I personally don't think it is that bad)
or some other format of certificate.

However, if one is to keep with cryptographically kosher practices,
there are the following constraints:

- The account key can not sign X.509 certificate, or any other
  certificate with format not based on JWS.
- The account key can not directly sign TLS key exchange. 

Also, another certificate format would require a new TLS certificate
format. Codepoint assignment needs an RFC, but in practice, those
would likely be annoying to implement.

Then there are the following implementation constraints:

- The key used to sign the TLS key exchange must appear the
  certificate.

-Ilari

---

From: Jonathan Rudenberg <[email-masked]>
Date: Fri, 12 Jan 2018 09:26:01 -0500

> On Jan 11, 2018, at 22:46, Matthew D. Hardeman <[email-masked]> wrote:
> 
> Hi, guys,
> 

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

> 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

---

From: "Matthew D. Hardeman" <[email-masked]>
Date: Fri, 12 Jan 2018 10:06:56 -0600

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-masked]> wrote:
> 
>