Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

Carrick Bartle <cbartle891@icloud.com> Mon, 02 August 2021 19:45 UTC

Return-Path: <cbartle891@icloud.com>
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 E1B623A1922 for <tls@ietfa.amsl.com>; Mon, 2 Aug 2021 12:45:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.845
X-Spam-Level:
X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com
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 W6ns4BeK8YzG for <tls@ietfa.amsl.com>; Mon, 2 Aug 2021 12:44:58 -0700 (PDT)
Received: from mr85p00im-hyfv06011401.me.com (mr85p00im-hyfv06011401.me.com [17.58.23.191]) (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 9905B3A191F for <tls@ietf.org>; Mon, 2 Aug 2021 12:44:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1627933498; bh=Bgzp5nvVZ0s4l3KJ+qLTdUiS3ty8cjiutc4aG0Psl6Q=; h=From:Content-Type:Mime-Version:Subject:Date:To:Message-Id; b=l2GayddDdtAd7KAzWdZMyTSMNFBFl4LMW+uRrZv9JsFa/AUhBhg2fcbu0sqmyY7Z4 ZH4/iEU5hO+MgiK91ntzR0IGc8qrSXxIGI64WmmEnvpsMLEIhbtwyoRRYnCfwrrUBL OwLLxI6qMfSVLvJIt5ezp8yV9ojuLlWaIIRoLKYd83eC53KlpjO/TRLNtM+XrB0++w Kh9SbGvo0wrKhFFLQ2PQJ0yjw7kGjd4XeR1MeM2GEnAzJ1+ONX9UsQNjVWjM4sM21s cnuorkXIADmQt/k8cPhmUS1Jwtfh6zOxd/49n2GjzXQCiuMDdKRNacbeoW9cm2TGS2 ii6qyToYvuMbg==
Received: from smtpclient.apple (unknown [17.11.125.166]) by mr85p00im-hyfv06011401.me.com (Postfix) with ESMTPSA id D5B1ED20474 for <tls@ietf.org>; Mon, 2 Aug 2021 19:44:57 +0000 (UTC)
From: Carrick Bartle <cbartle891@icloud.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
Date: Mon, 2 Aug 2021 12:44:57 -0700
References: <CAOgPGoARpxr8-FzYJPRcup9XF-DRv875aAnuNZtoLPHM9-6j-w@mail.gmail.com> <4c0aafd3-fc8f-453a-a009-44ecc18dafd7@www.fastmail.com> <YQNLizvBb/xZyxkl@straasha.imrryr.org> <SY4PR01MB6251677071C9EDF4E5149616EEEC9@SY4PR01MB6251.ausprd01.prod.outlook.com> <YQRLcoKm/+lVGwfv@straasha.imrryr.org> <BL3PR11MB5682F0455884BAC742324DD8C1EC9@BL3PR11MB5682.namprd11.prod.outlook.com> <YQRXGUZ/J7YZpzVv@straasha.imrryr.org>
To: "<tls@ietf.org>" <tls@ietf.org>
In-Reply-To: <YQRXGUZ/J7YZpzVv@straasha.imrryr.org>
Message-Id: <0C187E76-6610-4815-A228-5EC106027B64@icloud.com>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.391,18.0.790,17.0.607.475.0000000_definitions?= =?UTF-8?Q?=3D2021-08-02=5F07:2021-08-02=5F02,2021-08-02=5F07,2020-04-07?= =?UTF-8?Q?=5F01_signatures=3D0?=
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 suspectscore=0 adultscore=0 phishscore=0 mlxscore=0 spamscore=0 clxscore=1015 bulkscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2108020127
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/T-0wYPYtUjAriknlwBM86YeIHaE>
Subject: Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
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: Mon, 02 Aug 2021 19:45:05 -0000

Is there benefit in stating that the server SHOULD choose a safe group, even if the client is unable to negotiate one?

Either way, I would support deprecating FFDHE completely.


> On Jul 30, 2021, at 12:46 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> 
> On Fri, Jul 30, 2021 at 07:30:31PM +0000, Scott Fluhrer (sfluhrer) wrote:
> 
>>> Was it wrong to generate server-side DH parameters?
>> 
>> The problem is that it is hard for the client to distinguish between a
>> well designed server vs a server that isn't as well written, and
>> selects the DH group in a naïve way.
> 
> I am well aware that verifying the safety of the server's choice is
> computationally taxing.
> 
>> Now, as I mentioned in the WG meeting, it would be possible to detect
>> if the server proposes a safe prime (it's not especially cheap, being
>> several times as expensive as the rest of the DH operations, but it's
>> possible), and that would prevent most of the problems that can happen
> 
> I don't think it is realistic for the client to go to that much trouble.
> The server's choice of parameters is signed by the server's public key.
> What is the threat model here?  Is the client trying to avoid servers
> that shoot themselves in the foot by verifiably choosing bad parameters?
> 
> The server could also have a strong DH group, but a terrible RNG with a
> well known RSA private key:
> 
>    http://dnssec-stats.ant.isi.edu/~viktor/mailcow.html
> 
> If the server is not one of these or similar, and attests to its choice
> of DH parameters, and they happen to be less than ideal, so be it.
> Server operators should be encouraged to choose strong parameters, but I
> see little reason for clients to second-guess that choice.
> 
> If the DH parameter size is below a reasonable threshold (Logjam), a
> client might balk, but otherwise I am not sure what practical problem
> we're actually solving.
> 
>> Of course, this works only if the legacy servers you are talking about
>> actually do use safe primes...
> 
> All the ones I know of use "openssl dhparam", which defaults to Sophie
> Germain strong primes with generator 2.
> 
> I strongly doubt there's a non-negligible server population with weak
> locally generated groups.  The only likely source of weak groups is
> servers that used one the older now deemed weak groups published in
> deprecated RFCs.
> 
> So it might suffice to refuse specific known weak "standard" groups,
> which would have a much lower impact than requiring particular standard
> groups with no mechanism to negotiate these.
> 
> -- 
>    Viktor.
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls