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

[Geoffrey Keating <[e-mail]>]

Viktor Dukhovni <[e-mail]> 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 <[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?

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'.