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 <tls-boun...@ietf.org> on behalf of Nimrod Aviram 
<nimrod.avi...@gmail.com>
Date: Tuesday, April 6, 2021 at 05:28
To: "<tls@ietf.org>" <tls@ietf.org>
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


Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to