Re: [TLS] Static DH timing attack

Filippo Valsorda <> Sat, 12 September 2020 12:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5EB9C3A08F5 for <>; Sat, 12 Sep 2020 05:16:12 -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=QCBYHADG; dkim=pass (2048-bit key) header.b=T7GECTUF
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Xd0WkHyjRD4x for <>; Sat, 12 Sep 2020 05:16:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 52E403A08D4 for <>; Sat, 12 Sep 2020 05:16:10 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id A3EE75C0189; Sat, 12 Sep 2020 08:16:09 -0400 (EDT)
Received: from imap1 ([]) by compute3.internal (MEProxy); Sat, 12 Sep 2020 08:16:09 -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=3kK8gnDN9mPCCyCt/mF83PTXqnINnLG ++X49SRTzoCQ=; b=QCBYHADGYcVOufnOMPsBIlbwR3Zq/gvfh7PpriXrNfcC5eM S6uQuSZUTsKeQbTKTi5BX6Ypul+7gRGpfc4sBLiIv2ftrPPXp19dUytLD7NMA/mz dnGkHQSC7097by67l+092Eka/H5+uIsF+Qgae/whkv6o/L+ywo4yl3WMptma6S0h t+88Pkn603GlQaF9Ljgxbj9oVJaujm6N+/2Seah9WFQ9IUaTMFlpQKlw0IimX1Qw 6vWyTgkSSZRBUSIEEP+elvOn5pRFXC1uE8OC0k+lfqsaLH7kumpLKyuQCQiVYtX9 9nUQoOC6P43Ia4E2w+5kCK4pxXK+WORGoBu8mNw==
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=3kK8gn DN9mPCCyCt/mF83PTXqnINnLG++X49SRTzoCQ=; b=T7GECTUF6CXTVKnq1kSKgZ KjxNySTve4HTXigZ+5LuOS5+QWiOaqG9+8/SNFSYqK2WoIzXAlBqIWfLFQAQZh6s 930RxfsMZV3FMcpN/3BY5ez1gZhkyHt7erbBeE1zY7XZP1dBjiuNLNlZTNifdD+I gv7Sp6q5JVDpRQyDprgtS8+gI2hQFWAYuD1K6Ad4S94ImKGw+hkapi9Lal98g3hj ILlm6eCqUVh/ki5tkJm+aXMX5sB1MFUnkHf5jtK0Lb0fntRhe3yKez+0UtRVs8Bx BCDaQIQGwBoZKl5khJUAbH0XXACqbrrzsm6/NmRCf027F/GZC1DCDmExzShHgKCQ ==
X-ME-Sender: <xms:CbxcXx8pkNltRCBUA1NJ4AsyAqvd29YkJMt7z5muBRsv0MXyEHCdtA> <xme:CbxcX1t43TlskTfnKgMeWS-lp5z19fPCNv83jl_QgDyGGyZnKe_1WHtqolO583VCC v6CuxSdzEzWb1-jOg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudeiuddgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfhihhl ihhpphhoucggrghlshhorhgurgdfuceofhhilhhiphhpohesmhhlrdhfihhlihhpphhord hioheqnecuggftrfgrthhtvghrnhepffffueejgeekgfektefguddujeeltdfhhfeftddv ieejhffhvdeuuefgjeelhfehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepfhhilhhiphhpohesmhhlrdhfihhlihhpphhordhioh
X-ME-Proxy: <xmx:CbxcX_BYsnLHTGkgtbcsTPd7jLCBx80-KnfPnHNREupRP-PWLSytYQ> <xmx:CbxcX1fq-nMUADKM-uOv6eCMfPW24See-pJtmy7dN4VNv5wmkLhiTQ> <xmx:CbxcX2O114a5OJ204Vf2R4dHoN63Gf1OICH5P0p4PxAWWyIYCM2qaw> <xmx:CbxcX5Y7OF3oK1uP5XSrdxCj9TdHX9Vq5L8b-G68WlCbeyuubzF6mw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id EA268C200A5; Sat, 12 Sep 2020 08:16:08 -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: Sat, 12 Sep 2020 14:15:48 +0200
From: Filippo Valsorda <>
To: Peter Gutmann <>, "" <>
Content-Type: multipart/alternative; boundary="a19aae44e0c44a719b3eaa732de9e011"
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: Sat, 12 Sep 2020 12:16:12 -0000

2020-09-12 05:48 GMT+02:00 Peter Gutmann <>:
> Filippo Valsorda <> writes:
> >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.
> I agree with the first two but not the last.  Why is non-ephemeral DH a MUST
> NOT but non-ephemeral ECDH a SHOULD NOT?  There's nothing magic about the EC
> form that makes it any better or safer.

Non-ephemeral DH is affected by the Raccoon attack, ECDH is not.

> And for the FFDHE ciphersuites, they're not specified in a dangerous way,
> people implement them in a dangerous way.  You really have to go out of your
> way to get it wrong, in the case of RACCOON it's actually more effort to get
> it wrong (keep old copies of values floating around and reuse them over and
> over) than to get it right (generate a fresh value every time).  So it doesn't
> need a "don't do FFDHE", it needs a "here's a lot of stupid things you can do
> with FFDHE if you put your mind to it.  Don't do any of them".
> Or maybe it can be turned into a more general "here are some dumb things that
> people have done with TLS over the years.  Check your server to make sure
> you're not doing them".  Posting your web server's private key as a .p12 file
> in a subdirectory below $DocumentRoot, for example, would be high on my list.

There are two peers involved in ciphersuite selection, so recommending everyone avoids an unsafe ciphersuite can protect connections even if only one side takes the advice, and even if it's not the side that made the implementation error.