>>> I think the blanket prohibition of reuse of ECDHE keys is maybe not >>> really justified. >> >> Why is that? > > Because there are still many TLS (non-web) implementations that don't > do ECDHE.
I'm confused: if those implementations don't do ECDHE, what's wrong with prohibiting the way it's used? > * In practice security improves more when you raise the ceiling, > rather the floor. This sort of suggests that we should never deprecate anything, ever, no? > On Mar 8, 2021, at 7:57 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > On Mon, Mar 08, 2021 at 07:08:31PM -0800, Carrick Bartle wrote: > >>> I think the blanket prohibition of reuse of ECDHE keys is maybe not >>> really justified. >> >> Why is that? > > Because there are still many TLS (non-web) implementations that don't > do ECDHE. > > Is there a credible active MiTM attack that can cause a server and > client both capable of ECDHE to use FFDHE or RSA key exchange? > > If so, a properly scoped (to the web or the public Internet, ...) > deprecation of FFDHE and RSA key exchange is then justified. > > If not, then I am cursed to ever repeat a key message of RFC7435: > > * In practice security improves more when you raise the ceiling, > rather the floor. > > * If you set the bar too high, users will resort to less secure, > but more accessible technologies. > > If your basic protocol is basically sound (has downgrade-resistant > feature negotiation) then deprecation can be counter-productive in > the short to medium term, so long as a non-negligible fraction of > the installed base is then no longer tall enough to take the ride. > > Therefore, a better approach may be to recommend that for key > exchange ECDHE should be prioritised ahead of EDH and RSA. > > The effort may also be largely redundant, affecting only the > deployments that are likely to end up resorting to suboptimal > choices. > > Below, for example, is the default TLS 1.2 ordered cipherlist for > OpenSSL 1.1.1. All other parameters being equal, in each group > the order is kECDHE+aECDSA, kECDHE+aRSA and finally kDHE+aRSA: > > ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) > Mac=AEAD > ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) > Mac=AEAD > DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) > Mac=AEAD > > ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA > Enc=CHACHA20/POLY1305(256) Mac=AEAD > ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA > Enc=CHACHA20/POLY1305(256) Mac=AEAD > DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH Au=RSA > Enc=CHACHA20/POLY1305(256) Mac=AEAD > > ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) > Mac=AEAD > ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) > Mac=AEAD > DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) > Mac=AEAD > > ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) > Mac=SHA384 > ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) > Mac=SHA384 > DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) > Mac=SHA256 > > ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) > Mac=SHA256 > ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) > Mac=SHA256 > DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) > Mac=SHA256 > > ECDHE-ECDSA-AES256-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(256) > Mac=SHA1 > ECDHE-RSA-AES256-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(256) > Mac=SHA1 > DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) > Mac=SHA1 > > ECDHE-ECDSA-AES128-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(128) > Mac=SHA1 > ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) > Mac=SHA1 > DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) > Mac=SHA1 > > -- Finally, last resort kRSA > AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) > Mac=AEAD > AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) > Mac=AEAD > AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) > Mac=SHA256 > AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) > Mac=SHA256 > AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) > Mac=SHA1 > AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) > Mac=SHA1 > > There's hardly any need to goad the ecosystem to prefer ECDHE when > available, that's already done. > >>> IMO that's the part that should have deprecation of RSA cipher >>> suites done at the same time. > > Here of course RSA means RSA key exchange, not RSA signatures. > >> RSA seems to me to be too off-topic for this draft. (It also seems to >> me that RSA is still too widely used and not broken enough to merit >> deprecation.) If you think this draft requires that RSA key exchange >> also be deprecated, that could be done in a parallel draft. > > I think there's a valid point here, either deprecate "kRSA" first > or both together. Making it clear that no auditor's checklist > should become "green" by disabling DHE and leaving just RSA > key exchange standing. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
