Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)

[Viktor Dukhovni <[e-mail]>]

> On Nov 7, 2018, at 6:07 PM, Geoffrey Keating <[e-mail]> wrote:
> 
> n general, though, what you're asking is "The CA signing this key has
> instructed that I do not accept signatures made with it.  Is it OK to
> accept signatures made with it?" It's really hard to see how the
> answer to that could generally be 'yes'.

Thanks for everyone's input, this has been very helpful.  The approach
I'm inclined to take is as follows:

1. Always enforce key usage for your own certificate, ensuring key
   separation as provisioned at the time of key/certificate creation.
   This also maximizes opportunities for problems to be detected early
   and fixed.

2. Always enforce peer certificate key usage (separation) for ECDSA.
   ECDSA keys are more brittle when misused.

3. Enforce RSA peer certificate key usage when RSA key transport is locally
   disabled, allowing only (EC)DHE-RSA.  This is always the case with TLS 1.3,
   but for TLS <= 1.2 subject to the enabled ciphers.

The rationale for 3 is as follows:

   * The primary responsibility for doing key separation right falls on the
     key holder (as in 1).  If that's always done correctly, the peer has
     nothing to second-guess.

   * If the key holder has no key separation, and makes key recovery
     possible through some sort of side-channel, then the attacker who
     recovers the key can always misuse that key via whichever key
     exchange is allowed by the certificate, when all are accepted by
     the client.

     Therefore, if the client supports both RSA key exchange and (EC)DHE-RSA,
     the attacker wins regardless of any effort by the client to enforce key
     usages.

     Which leaves the case where the client only accepts (EC)DHE-RSA (as with
     TLS 1.3 or TLS 1.2 with the RSA key exchange features disabled).  In that
     case, if the attacker is able to compromise a server key constrained to
     "keyEncipherment", but cannot obtain a fraudulent certificate, then he'd have
     a certificate for just "keyEncipherment" which the client will refuse to
     honour for "digitalSignature".  And so the client actually gets some measure
     of protection by doing keyUsage enforcement.

This approach also has the advantage that legacy cases continue to (mis)behave
like they always did, but the strictness rises to match the client's protocol
preferences wether through use of TLS 1.3 (fresh start, fresh constraints) or
by restricting TLS 1.2 ciphers in a way that makes keyUsage enforcement a
practical counter-measure to at least some potential attacks.

-- 
	Viktor.