Re: [TLS] Static DH timing attack

Russ Housley <housley@vigilsec.com> Fri, 11 September 2020 14:06 UTC

Return-Path: <housley@vigilsec.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 A976C3A09C5 for <tls@ietfa.amsl.com>; Fri, 11 Sep 2020 07:06:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 30e2hSV24fFv for <tls@ietfa.amsl.com>; Fri, 11 Sep 2020 07:06:24 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89F553A0414 for <tls@ietf.org>; Fri, 11 Sep 2020 07:06:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 05095300AB1 for <tls@ietf.org>; Fri, 11 Sep 2020 10:06:22 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FJcsxcH6wllO for <tls@ietf.org>; Fri, 11 Sep 2020 10:06:19 -0400 (EDT)
Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 27E1630009B; Fri, 11 Sep 2020 10:06:18 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <1599790864561.88777@cs.auckland.ac.nz>
Date: Fri, 11 Sep 2020 10:06:18 -0400
Cc: IETF TLS <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6B1CC8B1-C497-4E80-9067-3147124F7AE4@vigilsec.com>
References: <5595BB40-3AFD-4327-B7B7-5E63FFC594DD@akamai.com> <1599729784370.87441@cs.auckland.ac.nz> <fff1a66a-0a49-cfbd-461a-c1d0ed3aeaaa@gmx.net> <1599790864561.88777@cs.auckland.ac.nz>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
X-Mailer: Apple Mail (2.3445.104.15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ZmjiNHX5Vs99j41mVybqBRBWkZ8>
Subject: Re: [TLS] Static DH timing attack
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: Fri, 11 Sep 2020 14:06:26 -0000

Peter:

> Achim Kraus <achimkraus@gmx.net> 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