Yes to what Viktor proposed. On 11/7/18, 11:27 PM, "TLS on behalf of Viktor Dukhovni" <tls-boun...@ietf.org on behalf of ietf-d...@dukhovni.org> wrote:
> On Nov 7, 2018, at 6:07 PM, Geoffrey Keating <geo...@geoffk.org> 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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
