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

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

Yes to what Viktor proposed.

On 11/7/18, 11:27 PM, "TLS on behalf of Viktor Dukhovni" <[e-mail] on behalf of [e-mail]> wrote:

    > 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.
    
    _______________________________________________
    TLS mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/tls