As has been pointed out, TLS is *not* just the Web. And TLS peers are not necessarily browsers.
Yes, there are reasons to avoid deprecating FFDHE with RSA signatures on the
open Internet (besides that doing it would be silly counterproductive, as not
everybody uses ECC).
Limiting FFDHE to well-known groups would probably be a good idea. Though it
would be educational to hear from those who for some reasons need weird
“special” groups of weird sizes.
--
Regards,
Uri
There are two ways to design a system. One is to make is so simple there are
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
- C. A. R. Hoare
From: TLS <[email protected]> on behalf of Nimrod Aviram
<[email protected]>
Date: Tuesday, April 6, 2021 at 05:28
To: "<[email protected]>" <[email protected]>
Subject: [TLS] Deprecating FFDHE + RSA Key Exchange
Dear all,
Following the discussion around draft-bartle-tls-deprecate-ffdhe, what are your
thoughts on deprecating RSA key exchange, and Finite-Field Diffie-Hellman?
(This would probably happen in a separate document.)
Considering the following different areas/use cases:
1. On the open Internet/web, both key exchange methods have been superseded by
ECDH. Browser support for FFDHE has been entirely removed IIUC, so formally
deprecating FFDHE should not be a problem (right?). Are there any reasons to
avoid deprecating FFDHE and RSA on the open Internet?
2. On local networks, deprecating both key exchange methods may leave some
endpoints without any key exchange algorithms. Could you please give feedback
on the following:
a. Is the number of such endpoints large enough that we shouldn’t deprecate
these methods?
b. If the answer to the above is yes, what would be a good plan/timeline to
deprecate them?
We could also consider limiting FFDHE to well-known groups of at least 2048
bits, with fully ephemeral secrets. But this would likely cause enough
interoperability problems that we might as well deprecate it fully, right?
thanks,
Nimrod
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
