I suggest that custom parameters should be allowed, and documented as completely under user/administrator responsibility.
Ensuring that a custom modulus is not "too small" or "too large" (etc.) in that
case is not your problem or your business.
On 10/12/20, 13:32, "TLS on behalf of Ilari Liusvaara" <tls-boun...@ietf.org
on behalf of ilariliusva...@welho.com> wrote:
On Mon, Oct 12, 2020 at 12:36:06PM -0400, Michael D'Errico wrote:
>
> It appears that there may be a need to revert to the
> old way of sending Diffie-Hellman parameters that
> the server generates. I see that TLS 1.3 removed
> this capability*; is there any way to add it back?
The Diffie-Hellman support in TLS 1.2 is severly broken. There is no
way to use it safely on client side. This has lead to e.g., all the web
browers to remove support for it.
There is no way to ensure that the parameters sent are not totally
broken, e.g.:
- Modulus too small.
- Modulus too large.
- Modulus not prime (has been used as a backdoor!).
- Modulus is weak (possibly backdoored).
- Subgroup order does not have large prime factor.
Even checking the third would require primality test, and primality
tests at relevant sizes are slow. And the fourth and fifth can not be
checked at all in general case.
For ECDHE, TLS 1.2 allowed server to specify custom curve to do the
key exchange with. Rightfully pretty much nobody implemented that.
I think TLS WG should withdraw recommendation (as flawed) on all
TLS_DHE_* ciphersuites.
-Ilari
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
