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

Henrick Hellström <henrick@streamsec.se> Tue, 13 October 2020 05:43 UTC

Return-Path: <henrick@streamsec.se>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04953A0E5E for <tls@ietfa.amsl.com>; Mon, 12 Oct 2020 22:43:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level:
X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2tMi5wt9Gzj for <tls@ietfa.amsl.com>; Mon, 12 Oct 2020 22:43:01 -0700 (PDT)
Received: from vsp5.ballou.se (vsp5.ballou.se [91.189.40.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED53F3A0E5C for <tls@ietf.org>; Mon, 12 Oct 2020 22:43:00 -0700 (PDT)
X-Halon-Scanned: 7f4a955dd6f4c149d51110a345668da22aa82d04
Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp5.ballou.se (Halon) with ESMTP id f1919bcd-0d16-11eb-ad6e-0050568f70bb; Tue, 13 Oct 2020 07:42:55 +0200 (CEST)
Received: from [192.168.10.175] (c-89c7e155.39906-0-69706f6e6c79.bbcust.telenor.se [85.225.199.137]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 8F5F370C for <tls@ietf.org>; Tue, 13 Oct 2020 07:42:55 +0200 (CEST)
Reply-To: henrick@streamsec.se
To: tls@ietf.org
References: <8f57527d-efba-4d03-a3e5-f0ee33463d56@www.fastmail.com> <20201012172852.GA2560734@LK-Perkele-VII>
From: Henrick Hellström <henrick@streamsec.se>
Message-ID: <2ebd6123-1816-54aa-0585-eb0b638517fd@streamsec.se>
Date: Tue, 13 Oct 2020 07:42:52 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <20201012172852.GA2560734@LK-Perkele-VII>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030409020208070403040005"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/9Wfj8GN7IBhYASSifdxQs9h9d8s>
Subject: Re: [TLS] Sending Custom DHE Parameters in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Oct 2020 05:43:03 -0000

On 2020-10-12 19:28, Ilari Liusvaara 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.

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.


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