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

[Ilari Liusvaara <[e-mail]>]

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.
> 
> Consider:  The new mechanism is implemented and Let’s Encrypt
> deploys.
> 
> 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.

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