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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sat, 31 July 2021 12:54 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 BCD4D3A2527 for <tls@ietfa.amsl.com>; Sat, 31 Jul 2021 05:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 sr7atc-5nmZP for <tls@ietfa.amsl.com>; Sat, 31 Jul 2021 05:54:09 -0700 (PDT)
Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [180.189.28.117]) (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 20D903A2526 for <tls@ietf.org>; Sat, 31 Jul 2021 05:54:08 -0700 (PDT)
Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01lp2238.outbound.protection.outlook.com [104.47.71.238]) (Using TLS) by relay.mimecast.com with ESMTP id au-mta-21-YGoyRZdnPn2HOllGIhJmqQ-1; Sat, 31 Jul 2021 22:54:04 +1000
X-MC-Unique: YGoyRZdnPn2HOllGIhJmqQ-1
Received: from SY4PR01MB6251.ausprd01.prod.outlook.com (2603:10c6:10:10b::10) by SYXPR01MB1967.ausprd01.prod.outlook.com (2603:10c6:0:2a::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.21; Sat, 31 Jul 2021 12:54:02 +0000
Received: from SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::98a4:33de:1d06:e141]) by SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::98a4:33de:1d06:e141%3]) with mapi id 15.20.4373.026; Sat, 31 Jul 2021 12:54:02 +0000
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "Scott Fluhrer (sfluhrer)" <sfluhrer=40cisco.com@dmarc.ietf.org>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
Thread-Index: AQHXhNw9hZMv7zd4Dke27Husna/eB6ta+ZesgADl/wCAAAlpgIABI2IQ
Date: Sat, 31 Jul 2021 12:54:02 +0000
Message-ID: <SY4PR01MB6251BBD1E968DB0D506A3C1CEEED9@SY4PR01MB6251.ausprd01.prod.outlook.com>
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>
In-Reply-To: <BL3PR11MB5682F0455884BAC742324DD8C1EC9@BL3PR11MB5682.namprd11.prod.outlook.com>
Accept-Language: en-NZ, en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: be419a32-7151-45da-9849-08d9542245f3
x-ms-traffictypediagnostic: SYXPR01MB1967:
x-microsoft-antispam-prvs: <SYXPR01MB1967F4EF8B6BE5CD29E82DCAEEED9@SYXPR01MB1967.ausprd01.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0
x-microsoft-antispam-message-info: TO0xw9puZ9Xwd9lfgSfHqq7UUbZS5lIrkgerZK7fnfX6DlQjGV929mcOA3NIvThpRT3IC4MOcIxPkbA5nOiAxRe7Nin/jeYB+cXefVeEKzb4yzdIbf5rb3wpAIuI8Rox4v2ndMO/hqNgO4lAazDHDmc2eusVvjOSvI1OIHFuhF9tT06g7ql7nL2OdJ2LtRIK4PM6hqU+/BwcHQthkd6YyW2jLvc/5VRyFKOd9DyvHRHPR6d2wCoJKCkkUl0ZJ0Ses3Qd7NVXBAHTf87bxV+HSmxfebro330kVTF+ufoaig50nrhFSy186hs+JnvsmXnsZdj2/vHIOodscHV3WGaZ31KTo9GHXLtrHnak1fndB1G87G9tagcZv09+d48DNQ8NpSoF8M/v6st4xW4/HVgJkDd2S8TQd9uhtvqFW2MSTUDzb+AqbF6bvm9ZAY35ia9P69S2fwi+etKNv/Gp4cUQvGACFlIKyidEdN6sOff45wQP6TPN/qkXgY/VIbpV+BKB5xvfRcVXGkku25C8J1FmZRFaC3+zSVmDllIuL3ufvA283MPcDi49tCT25pagL9YYZxZQRa3qeaGA+zDKyvoseDxZrOsB72lTs0ZCrvamzMJy1tIBNbrbFwRsStlL2ToKdpFCV6jg2YcGIydanfkozYKlqfreKyMgAc1u/rbm/zu9IYzp7fWpbMQi2G36wovRusHl6vhgNJYJkZ5y5sq3og==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4PR01MB6251.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(366004)(39850400004)(376002)(346002)(9686003)(66574015)(66556008)(64756008)(478600001)(6506007)(66946007)(66476007)(76116006)(26005)(2906002)(55016002)(8676002)(186003)(4744005)(786003)(83380400001)(316002)(122000001)(38100700002)(110136005)(52536014)(8936002)(66446008)(7696005)(86362001)(38070700005)(5660300002)(33656002)(71200400001); DIR:OUT; SFP:1101
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: GkYkoBYHsEcf8EQ6aeaM4Xqel6zQuafcG0gAT10KSeOjxPF6/J+wl9lDJGxopesrDB3/dXiYAkoZFIIW12G1beX8/yKoOpgV9IJSXgsNe9V5YJCo4e1Ntv+vN4430Z6654uHnrNubhxLwhZ77fNqorhYNA3vfYM6wEs4XoSg5jhFoxS7nY36pUuyBEDjGuTqrmSz55CXMB7f6rGaLtxdPhKP9zC8tuoD92v8grejHKXXaPnnCS+3yBEsCUnYoUZ/y0zCJFl1ThErBqFEr5k4nr2ai240PReD9j+rI0M57x9W510JoD5p1DYVI6lVAv3QS/qOAjzhgfbh1T/E/xYgMwv/0shEhvBUYLzECWtnxIA2cj4F4JlRl0Ks08GEU00rOwHKRHhQKnX2InoYp2g3AyRJsTFBIA2/Zq8I9ITz1TEsSTkSOQrxqdadVqKzICtn7SJcO/KSwMCOBeB+0mw+bjis/LnxwIgPSfTgUdd11wuUa9wWF87P6RgnRFEHVWcEnHvmwfRpwrMTjamgdMAF6Xg/DOnOJbi66rXLcEJCwWpNOoUZfwVoiskxRJus2h7WOBYw5SgYGngCaIRn4qEhZeGCoxSBM+1HvLuY0rSnVoJJlFCSKne+YJrg/S92XaodvL9lsCxkH5it4Jn0p+G2Pk3FWG4MpYXnqpL49+ovmuA7MZ7YFFbrFZxhu87FPhrdxcOI1MG7J3PsbYzQQE7pFl7KmZ7s1wYufwcfCWFVpMHyJ+07iPGC3e9Hu7Oq1XW5DUzlIWsQIhkf+f7GFXSdOf9VPl/MPHEBW0pWrMJwLBxBnIfi109bCrhIf5lA5bPB0wBKCYN/y9G1195aZ3qZdaJRi2PyjPnMGp2OUTNfPux7p/0jgGwgph/g3RceRg5eHwBtIB6nldyfXMDIfVoV8Jv9KyO3nRB5C8wKKlQCgQH+sKEenXCl+XP6xcqh0cFpFJsHODFEg/jpDn1OGyTTNFJOvqUXedg4syAQ/LupAK1B7neOT8PwfTaF/2aeYDdxzO1KxjifFX11YiDQrOvQ3tACq8Mk2aDjhYDBr2e6Jiv8MNkVr8YAooOhw676LCl1HNu/MIVu0wPPivwM3+7+B45xpBsLrhYnH2RQAy4CV0rYHtE3teQYYNADBCTJB2M84Bsd0FLGKkKvqi1lwjQ6vAzjVxHdHxclmUrXb1Mc0djSg9deE01kb8k2hbX5pTXH8uQKAzfhmbU7X0Nsvnozqkbjduzx5FBHS9qBcAnyjFhDeufoAfCTJYI1sZJnfq80ecV7jFctl5p5PB6liW7YcKxcwmCeWO96aLrxvFBbHTs=
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: cs.auckland.ac.nz
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6251.ausprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: be419a32-7151-45da-9849-08d9542245f3
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2021 12:54:02.5254 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: d1b36e95-0d50-42e9-958f-b63fa906beaa
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: WvAes6aFi7J+DNpqd69lujJ935uN8dilhbpUXPZjTUU/eR/lFG3LlAbPZlNZysQts4huRoHCKV7xayMIpPKKHukLcyP+rqLZkNhZfjn+zNo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYXPR01MB1967
Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CAU17A13 smtp.mailfrom=pgut001@cs.auckland.ac.nz
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: cs.auckland.ac.nz
Content-Language: en-NZ
Content-Type: text/plain; charset="WINDOWS-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/SC6l3RxefOmJxUAyVxyJWk8tRxs>
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: Sat, 31 Jul 2021 12:54:14 -0000

Scott Fluhrer (sfluhrer) <sfluhrer=40cisco.com@dmarc.ietf.org> writes:

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

What should the client do if it could detect this?  And how would it
distinguish between a server that selects bad DH parameters, a server that
uses time() to seed its RNG for prime generation, a server that has a buffer
overflow allowing RCE, and a server whose ACLs allow read/write access to any
file on the filesystem including its private key(s)?

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

Or you could use TLS-LTS, which sends { p, q, g } allowing the client to
verify certain properties about the primes being used at next to no cost.

Peter.