Re: [TLS] Do we need DH?

Alyssa Rowan <akr@akr.io> Mon, 29 December 2014 12:53 UTC

Return-Path: <akr@akr.io>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7891A1A1B01 for <tls@ietfa.amsl.com>; Mon, 29 Dec 2014 04:53:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 90xMovWmePCX for <tls@ietfa.amsl.com>; Mon, 29 Dec 2014 04:53:05 -0800 (PST)
Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D2AC1A1B12 for <tls@ietf.org>; Mon, 29 Dec 2014 04:50:19 -0800 (PST)
Message-ID: <54A14E11.6060002@akr.io>
Date: Mon, 29 Dec 2014 12:50:25 +0000
From: Alyssa Rowan <akr@akr.io>
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.org>
References: <CACsn0cmD=YA4i889f--e_b-OahUVoYdKyQUaiUN--QKOmqn8uA@mail.gmail.com>
In-Reply-To: <CACsn0cmD=YA4i889f--e_b-OahUVoYdKyQUaiUN--QKOmqn8uA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IBTglnP0_O91_ayvGaFLK71HKlk
Subject: Re: [TLS] Do we need DH?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 29 Dec 2014 12:53:07 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 28/12/2014 22:38, Watson Ladd wrote:

> These show that the NSA has a comparatively easy time exploiting 
> static RSA.

When SIGINT/LE agencies later steal the keys; absolutely, they would,
as there's no forward-security. (Of course, we're fixing that.) They
also namedrop the Debian key low-entropy issue as a practical attack.

Nice historical graphs. No surprises. (Maybe we could FOIA and get
their statistical trends data to contribute on top of researchers'
existing TLS survey metrics! Might as well be good for something.
Of course, that would mean admitting they're doing mass surveys… <g>)

> From this it seems that performance actually matters: the slow
> speed of DH exchange compared to ECC explains why ECC, and not DH
> is replacing RSA.

Agreed. There was also the issue of >1024-bit DHE field selection,
interoperability, and Java 6.

> DH is also being attacked by PHOENIX: I can wild mass guess that
> this is batch FFS: I don't know if this has been researched
> extensively, and even batch NFS has only an asymptotic analysis.

They say PHOENIX is "publicly known" - so maybe it's simpler than that
and something already extensively researched in (what they would call)
the "open source" literature.

(The active attack replacing the field with a trivially-attacked one
that's addressed in TLS 1.2 by the ffdhe draft may be a potential
candidate, although I'm not sure if active attacks fit in the
flowchart there.)

> Given the low usage of the DH handshake, and potential 
> vulnerabilities (not potential, but certainly not as well
> understood) should we keep it in TLS 1.3?

Given the speed penalty, and the ffdhe difficulty, and this - I'd say
no, drop it. Finite-field DHE is worse than good ECDHE (and/or X25519).

(Non-ephemeral key agreement definitely needs to go, too; didn't Eric
already call for consensus on that?)

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUoU4RAAoJEOyEjtkWi2t6cecP/3c0E3Z0qaPCMEOuUhf2Z5Ym
1WJ6Y3N6srX0z6l3JwOqqqllUHWHnj2/aqoQDU++z1L5Y1vXppgUzPvCKvb6aMtN
Fjr9GeFXW/tWcOwSrtmB2Ta7knh85luu8bMaLp2SdrU+41h0sfFYYBUGec6RAiiF
HLMv5fpFavOOdDfMIfUfnfvDMKeC9Hkw5d16GJTPZZP93BetwUgQypf+Tedl/ATH
KbGAhqFB6c/svkUevdzXGhHcBoqlMbwG3RQNIjhHw6YinDgIuwZdCD9alxhSoQdb
lwKYG3smIcTCpRdiTcEZRpV3SCN36Q3ClkZWf0sVBCNM9LessyT3TRlXnjj8pec4
O8ZwfXjmc4YxLlrd787Eri2DRzv0nP1+V/Jdyz5uDhfn1LCArz8/cnJcW9PNd3Me
0FFZ3kL8n2PzXo4+K57K0jD8LpfbvWeIT6nUvBTfrAPTo4r8WCRLRxc3St5Zx2qL
fy9L6RHOlZEjC8cjI1YCxgrMlOQvK5j6WJY9K8GqltlQpcDkPhJNXEa9xBHuu12V
fO8VEIzHZOD6TZRTuK6oyXl102TVGVTbVGDE1H0gzsZWBJXNE6Ks5LbvkqJKE2ob
3v0wu5BF+xLPw/LdTQZaJowHXOFajU7LBlDIpH2PaCkk5n3ipSQejZceoGU0P0w0
7m0+CztnK1pFUAnp2jqD
=8Rac
-----END PGP SIGNATURE-----