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
