On Wed, Nov 7, 2018 at 1:12 AM Viktor Dukhovni <ietf-d...@dukhovni.org> 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 <geo...@geoffk.org> 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?
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
