Re: [TLS] Static DH timing attack

Dan Brown <> Thu, 10 September 2020 15:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E1373A0869; Thu, 10 Sep 2020 08:18:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iohNKLTL3JQm; Thu, 10 Sep 2020 08:18:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A44373A0801; Thu, 10 Sep 2020 08:18:02 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 08AFFaUs123530; Thu, 10 Sep 2020 11:18:00 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=corp19; bh=aTx3Fn+U5fEscbXZWlEV8BtH72FNTQ1jTxp8xXgrA5E=; b=T1Pbw4ZQRMngHnx6Nvrg6NdWyxWP0evRh4AOmWtBm/mQOn/ztbbgoqrgsYtkko6BvsOh lCe6gaDYd2B64V+OQDzKqf0FNhi7uooBPJMVy9Df2GmhgetRpmKQoFh/kqggmEdP8Jo4 hiIzRICOzhPaNKjeF/u4qNat8hOpiSKcZtbfjBCmRV6JxlFUVq0JAgPRNzJbvZRRoMkA aEwexumqX3d+8UE44X5zePNWXui4v8WoDGt0BT9zbn5OBdVfhPdzTUlEkWgTeoaKCnZy 5JZF7tGe7Y7RWtxWaa+txQ+A+HvNC2IJWnZYdVNXOVIJDogunfFx3UrkblBIpyEZ4nMJ hA==
Received: from ( []) by with ESMTP id 33c5x7avge-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 10 Sep 2020 11:18:00 -0400
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 10 Sep 2020 11:18:00 -0400
Received: from ([fe80::ac8d:3541:704c:478a]) by ([fe80::ac8d:3541:704c:478a%5]) with mapi id 15.01.1913.007; Thu, 10 Sep 2020 11:17:59 -0400
From: Dan Brown <>
To: "Salz, Rich" <>, "" <>
Thread-Topic: Static DH timing attack
Thread-Index: AQHWhrp+9EGmAKHnM0S2YOV3OYQKzqlh+Vhw
Date: Thu, 10 Sep 2020 15:17:59 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="2.16.840."; boundary="----=_NextPart_000_0038_01D68764.0978CF40"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-10_04:2020-09-10, 2020-09-10 signatures=0
Archived-At: <>
Subject: Re: [TLS] Static DH timing attack
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Sep 2020 15:18:05 -0000

From: TLS <> On Behalf Of Salz, Rich
> Do we need a short RFC saying “do not use static DH” ?


Don’t TLS 0-RTT and ESNI/ECH via HPKE use a type of (semi)static ECDH? If so, then an RFC to ban static (EC)DH in TLS would need to be very clear about not referring to these use cases of static ECDH.


My 2c. What about combining static ECDH (instead of signatures) with ephemeral ECDH, e.g. for more fully deniable authentication?  (ECMQV does this.)  (Perhaps this is also similar to the KEMTLS proposal for PQC, - still need to study that.)


This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.