> Suppose keyUsage is respected. Who will knowingly shoot themselves > in the foot and restrict their RSA certificate to just DHE or just > RSA key transport? This looks like an impractical counter-measure.
I guess we have to trade-off between different levels of “shooting oneself in the foot”. For a company that has a bunch of certificates, one for each domain, separate ECDSA and RSA certificates etc. spending a few more dollars on different certs for RSA encryption does not seem like a lot. In any case, the main issue is whether we can get recipients to enforce key usage, not senders. If a cert explicitly enables key exchange, encryption, and signature, it can be used for all of these. However, if the cert restricts itself to digital signature, then the client should not use it for RSA encryption. That way, the server gets to choose whether it wants protection from cross-protocol attacks or not, and the client will enforce its wishes correctly. Regarding ECDSA->ECDH cross-protocol attacks, the code that you pointed out in OpenSSL indeed allows the server to ensure it does not use a sign-only cert for ECDH, but other libraries do not make this distinction. Moreover, as far as I know, OpenSSL clients do not enforce this key usage restriction (See crypto/x509/x509type.c for the certificate usage rules.) Neither, for that matter do other TLS clients like NSS etc. This allows attacks like the ECDH downgrade in [1] and can probably make the ECDSA key recovery attack in [2] quite a bit worse. From the viewpoint of provable security, I’d be suspicious of any TLS modes that allow the same long-term keys to be used in multiple different ways. For RSA/EC, there are known attacks. But even otherwise, their use requires a strong joint security assumption that we don’t really know how to justify. -K. [1] https://www.smacktls.com/smack.pdf <https://www.smacktls.com/smack.pdf> [2] http://euklid.org/pdf/ECC_Invalid_Curve.pdf <http://euklid.org/pdf/ECC_Invalid_Curve.pdf> > > And by the way key usage is enforced by OpenSSL for EC. > > $ git grep -C3 X509v3_KU_ ssl > ssl/ssl_lib.c- X509_check_purpose(x, -1, 0); > ssl/ssl_lib.c-# ifndef OPENSSL_NO_ECDH > ssl/ssl_lib.c- ecdh_ok = (x->ex_flags & EXFLAG_KUSAGE) ? > ssl/ssl_lib.c: (x->ex_kusage & X509v3_KU_KEY_AGREEMENT) : 1; > ssl/ssl_lib.c-# endif > ssl/ssl_lib.c- ecdsa_ok = (x->ex_flags & EXFLAG_KUSAGE) ? > ssl/ssl_lib.c: (x->ex_kusage & X509v3_KU_DIGITAL_SIGNATURE) : 1; > ssl/ssl_lib.c- if (!(cpk->valid_flags & CERT_PKEY_SIGN)) > ssl/ssl_lib.c- ecdsa_ok = 0; > ssl/ssl_lib.c- ecc_pkey = X509_get_pubkey(x); > -- > ssl/ssl_lib.c- } > ssl/ssl_lib.c- if (alg_k & SSL_kECDHe || alg_k & SSL_kECDHr) { > ssl/ssl_lib.c- /* key usage, if present, must allow key agreement */ > ssl/ssl_lib.c: if (ku_reject(x, X509v3_KU_KEY_AGREEMENT)) { > ssl/ssl_lib.c- SSLerr(SSL_F_SSL_CHECK_SRVR_ECC_CERT_AND_ALG, > ssl/ssl_lib.c- SSL_R_ECC_CERT_NOT_FOR_KEY_AGREEMENT); > ssl/ssl_lib.c- return 0; > -- > ssl/ssl_lib.c- } > ssl/ssl_lib.c- if (alg_a & SSL_aECDSA) { > ssl/ssl_lib.c- /* key usage, if present, must allow signing */ > ssl/ssl_lib.c: if (ku_reject(x, X509v3_KU_DIGITAL_SIGNATURE)) { > ssl/ssl_lib.c- SSLerr(SSL_F_SSL_CHECK_SRVR_ECC_CERT_AND_ALG, > ssl/ssl_lib.c- SSL_R_ECC_CERT_NOT_FOR_SIGNING); > ssl/ssl_lib.c- return 0; > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
