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-----
- Re: [TLS] Do we need DH? Fedor Brunner
- Re: [TLS] Do we need DH? Tapio Sokura
- [TLS] Do we need DH? Watson Ladd
- Re: [TLS] Do we need DH? Alyssa Rowan
- Re: [TLS] Do we need DH? Yoav Nir
- Re: [TLS] Do we need DH? Peter Gutmann
- Re: [TLS] Do we need DH? Brian Smith
- Re: [TLS] Do we need DH? Maarten Bodewes
- Re: [TLS] Do we need DH? Hubert Kario
- Re: [TLS] Do we need DH? Yoav Nir
- Re: [TLS] Do we need DH? Alyssa Rowan
- Re: [TLS] Do we need DH? Nico Williams
- Re: [TLS] Do we need DH? Yoav Nir
- Re: [TLS] Do we need DH? Florian Weimer
- [TLS] Spec tls13 comments, handshake tampering, m… Michael Clark
- Re: [TLS] Spec tls13 comments, handshake tamperin… Michael Clark
- Re: [TLS] Spec tls13 comments, handshake tamperin… Nikos Mavrogiannopoulos