Subject: [TLS] Sending Custom DHE Parameters in TLS 1.3

From: "Michael D'Errico" <[email-masked]>
Date: Mon, 12 Oct 2020 12:36:06 -0400

Hi,

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?

Mike

*From RFC 8446:

- Other cryptographic improvements were made,
  including changing the RSA padding to use the RSA
  Probabilistic Signature Scheme (RSASSA-PSS), and
  the removal of compression, the Digital Signature
  Algorithm (DSA), and custom Ephemeral Diffie-
  Hellman (DHE) groups.

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 12 Oct 2020 20:28:52 +0300

> 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

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 12 Oct 2020 17:35:21 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    - Modulus too small.
    - Modulus too large.

    -Ilari

    _______________________________________________
    TLS mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/tls

---

From: "Michael D'Errico" <[email-masked]>
Date: Mon, 12 Oct 2020 14:06:31 -0400

Would it be possible to define a new dual-DH exchange
where you do one with server-supplied parameters, and
a second one with client-supplied parameters, so if one
is broken or sabotaged the connection is still secure?

Mike

On Mon, Oct 12, 2020, at 13:35, Blumenthal, Uri - 0553 - MITLL wrote:
> 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" 
> <[email-masked] on behalf of [email-masked]> wrote:
> 
> Attachments:
> * smime.p7s

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 12 Oct 2020 20:37:23 +0000

the server generates.

Can you explain why?  Something stronger than "I think that ..." is probably needed to convince the WG.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 12 Oct 2020 23:41:59 +0000

Ilari Liusvaara <[email-masked]> writes:

>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.

It's actually pretty simple, don't use toy key sizes.  Many implementations
were never vulnerable to Logjam et al because they applied the simple measure
of... not using toy key sizes.

>There is no way to ensure that the parameters sent are not totally broken,
>e.g.:

This requires that the server that you're connecting to is malicious.  If
you're connecting to a malicious server then you've got bigger things to worry
about then what they set g to.

>This has lead to e.g., all the web browers to remove support for it.

Because throwing out the baby with the bathwater and jumping on the next shiny
thing that comes along every time someone points out a problem seems to be a
requirement for crypto protocol implementers.

Peter.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 12 Oct 2020 23:50:07 +0000

In some cases toy key sizes are necessary. 

E.g., classes where your students break encryption because the keys are weak or small.

Regards,
Uri

> On Oct 12, 2020, at 19:42, Peter Gutmann <[email-masked]> wrote:
>

---

From: Henrick Hellström <[email-masked]>
Date: Tue, 13 Oct 2020 07:42:52 +0200

> browers to remove support for it.

You have to excuse me, but there is a fair amount of noise in this 
group, and it is sometimes hard to find the information you are looking 
for, in past discussions held years or even decades ago.

But surely DHE support can't be considered broken at the protocol level, 
because the client can't confirm that the server implementation of DHE 
parameter generation isn't broken? There are gazillion of ways the 
server implementation might be broken, that the client has absolutely no 
way to test, regardless of which TLS protocol it supports. I do not 
think I have to go into details.

If I remember correctly, the problem was rather that some of the most 
common implementations had made a habit out of using poorly chosen 
parameters, and the automated security testing tools couldn't easily 
tell flawed servers, from servers that had fixed this issue. It wasn't 
really a protocol issue, but purely an implementation issue.

Correct me if I remember incorrectly.

---

From: Hanno Böck <[email-masked]>
Date: Tue, 13 Oct 2020 08:49:39 +0200

Hi,

There was a reason custom DH parameters were removed.
Custom DH parameters were the source of plenty of problems.

I suggest reading:
https://blog.hboeck.de/archives/841-Diffie-Hellman-and-TLS-with-nonsense-parameters.html
https://eprint.iacr.org/2016/644
https://www.openssl.org/news/secadv/20160128.txt

There's also a more general theme I think what we have learned over
time:
Moving parts in crypto protocols are bad, simplicity is good. Fix as
much as you can, avoid negotiating stuff.

This is not talked about that much explicitly, but it is a major change
of how crypto protocols were designed in the past (i.e. TLS 1.2 times)
where it was often considered desirable to add as much flexibility as
possible.

(Also FWIW the relevance of DH is pretty small these days. I think the
largest web clients simply don't support it at all.)

-- 
Hanno Böck
https://hboeck.de/

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 15 Oct 2020 02:18:12 +0000

>https://www.openssl.org/news/secadv/20160128.txt

This just confirms what I said previously, this is an overreaction to a
completely artificial situation.  The first link is to a problem with a badly
broken implementation, the second and third are to the use of maliciously-
generated parameters.  If your server is deliberately serving up malicious
parameters then you have bigger things to worry about than the crypto.

To put this another way, if I show that a malicious server can break TLS 1.3,
does that mean we have to throw it out and start bikeshedding TLS 1.4?

Peter.