Re: [TLS] Static DH timing attack

Filippo Valsorda <> Fri, 11 September 2020 17:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F0C63A0E2C for <>; Fri, 11 Sep 2020 10:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=e7hZp5j4; dkim=pass (2048-bit key) header.b=fIJ8D9bl
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ckZ88hFBpGeL for <>; Fri, 11 Sep 2020 10:51:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4CADA3A0D20 for <>; Fri, 11 Sep 2020 10:51:32 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id A0AA85C020B for <>; Fri, 11 Sep 2020 13:51:31 -0400 (EDT)
Received: from imap1 ([]) by compute3.internal (MEProxy); Fri, 11 Sep 2020 13:51:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=9KEe/1C/n1feC4fN3X4oWzAwZ1YxOzR c8yLJjVto+2Y=; b=e7hZp5j4r6N0N2zrZVXSnKjBAJIxetNM2bnD1nCahypd1Zr F7sUFjIn3/QKlJLplXvCacuGhRrvE6kMOXvXdrZgPLIHafkhkPPh49RxJFZgywGr rIGHa50sDCe5Mux6B33zYwdG5ShgS34sElRtyOWdCGc7TsB96dtW5uTf7AF/SfJ/ qSgXIEx2CpaQXcJRv/a98s7I+3V3KxvfZmWrTbs5KuJ4ym1cg5kqh/xBZWlGejYh mUWwpni5l7qTXjsjYjD2A8uV73SE8rYTtfNnWgTvyUR0Gr2LQBvr1XZUpWOePAAN EGWkwuDAif3KnslM2dn1fsWRfhMOhAMAJf1/8Qg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=9KEe/1 C/n1feC4fN3X4oWzAwZ1YxOzRc8yLJjVto+2Y=; b=fIJ8D9bl0G18QqEEzdi3vh BKyDlEn3HLdwfEP5zh74IDlyw3dmrZY9tumhrDGxK+yyrU3mit0TDRt1pJUp7mzz aGBj9naTHaboXfDAeCGYNfMP6/2zJAwIdBjk6j8FJ10ARTBVdrE6/EXcfcjJQTVh q4DkooQzCz4j9nd18x80z+mXph/KSZzeSGZCIkyzR/vMIAwUk21eQvDakCqd2spb 5U/LecEkswegnAsQQLGd3jNEyLAGViA7XSGiYdSR9U1/VGPPxhPZgm6NdLrdyp+p 7+Gmn+wo+gp9m+qUTxXsf5nRHnYwjpWpGDMr4IvCuQ9FKpPi4DYnMWXwrzqr9VOQ ==
X-ME-Sender: <xms:IblbXyyzc30ffgXQAh9ZJp49fkRCpUDFRer7CXA1IX1g6QF9CA_uqQ> <xme:IblbX-TtwvlK-bWG-rOrZJF1rD-u3sCPmlQFmrGCTW7WsIvYuQyD1p_pT1eurBl_N dVKpD3ly87sCXuEvA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehledguddvtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrg dtreerreerjeenucfhrhhomhepfdfhihhlihhpphhoucggrghlshhorhgurgdfuceofhhi lhhiphhpohesmhhlrdhfihhlihhpphhordhioheqnecuggftrfgrthhtvghrnhepudfhhe evhfekteetkeetvdejjedtheejtddujeeujeffudfhtedufedvhfekkedvnecuffhomhgr ihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehfihhlihhpphhosehmlhdrfhhilhhiphhpohdrihho
X-ME-Proxy: <xmx:IblbX0V6SnfOFlHEmXKfJ8wt2BwjCSIfqPUyYCzdNWYHzeJFFywEHg> <xmx:IblbX4h5D4dLgY_YYYykxrZ6NHKTsdVxAH4gh1CV7ve5VJzJfDlUjw> <xmx:IblbX0Czap64oL-v7rGXA9mwWxaEo9j3IWHGScu4wCwHtQTe3CoR8A> <xmx:I7lbX3PX3s3EWrEKycjir_DzmJ-g1eTOZLE0JNryjuXJBT3lPrnUBw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 82F6EC200A5; Fri, 11 Sep 2020 13:51:29 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-259-g88fbbfa-fm-20200903.003-g88fbbfa3
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <> <>
Date: Fri, 11 Sep 2020 19:49:44 +0200
From: Filippo Valsorda <>
Content-Type: multipart/alternative; boundary="089967dd98384c3fb188fdf9f2d8e1ca"
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: Fri, 11 Sep 2020 17:51:34 -0000

I feel like there should be nothing controversial in the context of TLS.
 * Non-ephemeral FFDHE ciphersuites in TLS 1.0–1.2 (TLS_DH_*) ought to be a MUST NOT, because they can't be implemented securely.
 * Reusing ephemeral shares for ECDHE and DHE ought to be a MUST NOT in all TLS versions, because it's unnecessary and has been a requirement for many attacks now.
 * Non-ephemeral ECDH ciphersuites (TLS_ECDH_*) ought to be a SHOULD NOT, because again ECDH share reuse enables a whole class of attacks.
 * FFDHE ciphersuites in TLS 1.0–1.2 (TLS_DHE_*) ought to be a SHOULD NOT, because they are specified in a dangerous way that is not secure if shares are reused.
If any of the above are not already the case, it should be a quick and easy document.

2020-09-11 16:06 GMT+02:00 Russ Housley <>:
> Peter:
> > Achim Kraus <> writes:
> > 
> >> Does using x25519 for ECDHE is significant less secure than using it with
> >> e.g. secp384r1?
> > 
> > The NIST curves AFAIK are never used that way, it's only done with 25519
> > (there was something about it in an OpenPGP draft, but I think GPG went
> > straight to 25519 and only used ECDSA for signatures).
> > 
> > What I'm specifically referring to is DH run sideways, as someone put it
> > during the X9.42 discussion, i.e. used in static-ephemeral mode to try and
> > make it work like it's RSA.
> > 
> > In all the code audits I've done of 25519 used that way, I've never seen it
> > used correctly.  Usually there isn't just one mistake made but many of them.
> > It's such an obvious problem that that and misuse of RC4-equivalent modes/
> > algorithms like GCM and ChaCha20 are the first things I look for in crypto
> > code.
> I am sure you know that ephemeral-static DH was original used for S/MIME.  The reasoning for ephemeral-static DH was not to make it work like RSA.  Rather, the idea was to provide authentication of the static DH key holder by certifying the static DH public key.  Then, the ephemeral DH key pair is generated using the parameters from the certificate.  One important aspect of this approach was to avoid picking a single group for all of the DH keys.
> Russ
> _______________________________________________
> TLS mailing list