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

[David Benjamin <[e-mail]>]

On Wed, Nov 7, 2018 at 1:12 AM Viktor Dukhovni <[e-mail]>
wrote:

> [ Quoted text slightly reordered to put the RSA issue first, as that's
>   the main thing I'm trying to get clarity on, and enabling keyUsage
>   enforcement is causing some interoperability issues now... ]
>
> > On Nov 5, 2018, at 11:11 PM, Geoffrey Keating <[e-mail]> wrote:
> >
> >> TL;DR:  Should TLS client abort DHE-RSA handshakes with a peer
> >> certificate that *only* lists:
> >>
> >>            X509v3 Key Usage:
> >>                Key Encipherment, Data Encipherment
> >
> > Yes, because in DHE-RSA, the RSA key is used for signing, and this is
> > an encryption-only key.
> >
>
> > As far as I know there's no similar attack on RSA, but I think this is
> > not a well-examined area.
>
> Since the vast majority of certificates in the wild are RSA, and
> interoperability is a concern, I'd really like to better understand
> what risk if any posed if one allows a an *RSA* key with a keyUsage
> of "keyEncipherment" (seen on some live servers that then do DHE-RSA)
> to be used for "DigitalSignature"?  I am only aware of risks in the
> converse direction.  How unreasonable would it be to be more forgiving
> and allow *RSA* "DigitalSignature" when the keyUsage indicates otherwise?
>

This seems flipped to me. Which attacks do you see enforcing
keyEncipherment blocking? If you are concerned about Bleichenbacher-type
private key oracles, it should be more important to enforce
digitalSignature, and even that's not sufficient in itself (cf. DROWN
affecting non-SSLv2 clients too).

A private key oracle allows both ciphertext decryption *and* signature
forgery, so we need clients to know which forged signatures to reject, and
for an uncompromised path to be possible. Thus, if you believe the server's
RSA key exchange implementation admits a private key oracle and that oracle
is efficient enough for online attacks[*], I believe you need all of the
following for the client to not care:

1. The server uses separate keys for RSA encryption and RSA signing. It
will never use its RSA signing key for RSA encryption.
2. The server key separation is reflected in keyUsage bits, which is
enforced by the client in (EC)DHE_RSA modes.
3. The client doesn't accept RSA key exchange at all.

If all are true, the client will never accept the encryption key and the
signing key is uncompromised, so we're fine. If any of the above are false,
I don't think it works.

If the server shares RSA and (EC)DHE_RSA keys (1), as everyone does, its
one and only key is effectively compromised and there's not a whole lot one
can do, short of fixing or disabling the RSA key exchange implementation on
the server.

If the client ignores keyUsage in (EC)DHE_RSA (2), as most do, the server's
key separation is moot. The client doesn't know to reject a
private-key-oracle-forged signature.

If the client still supports RSA key exchange (3), as most do, none of this
key separation matters, because the attacker can just negotiate RSA key
exchange anyway.

My experience is that typically none of (1), (2), or (3) happen, much less
all, so this is all kind of moot. :-)

Re (2), historically we'd seen issues with MITM proxies minting certs
incorrectly, BoringSSL only enforces key usage for RSA starting TLS 1.3 (it
was new, so get it right from the start) and ECDSA at all versions (only
one value in practice, seems to have worked out). I started gathering more
current metrics a while back but haven't had time to follow-up on this yet.
But as most clients sadly still have to support RSA key exchange (3) and
managing two certificates (1) is onerous for most server, I doubt any
fixing that will help in practice for a while, if ever. It's more an
ecosystem health thing.

David

[*] If you believe the oracle isn't efficient enough for online attacks,
you probably can just lean on downgrade protection ratcheting you to
(EC)DHE_RSA and call it a day?