Viktor Dukhovni <ietf-d...@dukhovni.org> writes: > [ 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?
Maybe I should expand on my previous answer. There is, obviously, an attack with RSA under some circumstances. If you have an oracle where the attacker can see the results of any RSA decryption, then this leads directly to the ability to forge a signature. In more practical situations, the attacker doesn't get to see the results. Instead, for example in properly-implemented TLS, the attacker only learns whether the decryption was successful, relative to a key chosen by the attacker, and a 'successful' decryption includes a padding check of the output which is highly unlikely to succeed for a fixed input. So there doesn't seem to be a direct attack in this situation. However, how do you know this is the situation? There is the obvious question about improper implementations. How do you know that this key wasn't configured this way because there's a known security issue which might leak a key used for encryption, and the key is intended only to be presented to hosts which will not accept DHE? This is particularly relevant because we do know of some attacks on PKCS#1v1.5 encryption, which make the 'proper implementation' quite complicated, and you can see the result in RFC 3218. However these attacks were concerned primarily with recovering the symmetric key, and not forging a signature using the RSA key. I don't think anyone has deeply investigated the signature-forging issue in this context, since typically if you can recover the symmetric key, that's bad enough (you can just force the connection to use an encryption-based ciphersuite). In 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'. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
