Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)
Geoffrey Keating <geoffk@geoffk.org> Fri, 19 August 2016 18:35 UTC
Return-Path: <geoffk@geoffk.org>
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 213B012DA2A for <tls@ietfa.amsl.com>; Fri, 19 Aug 2016 11:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 OOq9XO9j2-ru for <tls@ietfa.amsl.com>; Fri, 19 Aug 2016 11:35:46 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1E0312DA29 for <tls@ietf.org>; Fri, 19 Aug 2016 11:35:45 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 5906133D20D; Fri, 19 Aug 2016 18:35:45 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz> <20160816145548.GQ4670@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4CF1AC9@uxcn10-5.UoA.auckland.ac.nz> <CADMpkc+vbkWz_TQ2Ch5JfaVRPse4qeXPPitsBV=d2yDtSx4eLA@mail.gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4CF416C@uxcn10-5.UoA.auckland.ac.nz>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: Fri, 19 Aug 2016 11:35:45 -0700
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CF416C@uxcn10-5.UoA.auckland.ac.nz>
Message-ID: <m260qwppxa.fsf@localhost.localdomain>
Lines: 22
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/I3hATzFWwkc2GZqt3hB8QX4c-CA>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 19 Aug 2016 18:35:49 -0000
Peter Gutmann <pgut001@cs.auckland.ac.nz> writes: > The problem is that 7919 doesn't say "I want to do DHE, if possible > with these parameters", it says "I will only accept DHE if you use > these parameters, otherwise you cannot use DHE but must drop back to > RSA". Talk about cutting off your nose to spite your face, you'd > have to have rocks in your head to want to break your implementation > like that. Actually, my problem with the RFC is the reverse. If you have an implementation which won't accept certain DH groups, and those are extremely common in legacy software (1024-bit, for example), there's no way to stop those legacy implementations ignoring the extension and choosing DH, which you will then have to reject, doubling connection establishment time. So Apple's client still has DH off. However I don't see a helpful solution to this; the obvious thing is to have a new ciphersuite, but it's hard to see how that would be worth the effort if it requires new implementations and ECDHE is already standardised and already implemented in many places.
- Re: [TLS] RFC 7919 on Negotiated Finite Field Dif… David Benjamin
- Re: [TLS] RFC 7919 on Negotiated Finite Field Dif… Geoffrey Keating
- Re: [TLS] RFC 7919 on Negotiated Finite Field Dif… Watson Ladd
- Re: [TLS] RFC 7919 on Negotiated Finite Field Dif… Ilari Liusvaara
- Re: [TLS] RFC 7919 on Negotiated Finite Field Dif… Peter Gutmann
- Re: [TLS] RFC 7919 on Negotiated Finite Field Dif… Ilari Liusvaara
- Re: [TLS] RFC 7919 on Negotiated Finite Field Dif… Peter Gutmann
- Re: [TLS] RFC 7919 on Negotiated Finite Field Dif… Geoffrey Keating
- Re: [TLS] RFC 7919 on Negotiated Finite Field Dif… Bodo Moeller
- Re: [TLS] RFC 7919 on Negotiated Finite Field Dif… Peter Gutmann
- Re: [TLS] RFC 7919 on Negotiated Finite Field Dif… Watson Ladd
- Re: [TLS] RFC 7919 on Negotiated Finite Field Dif… Benjamin Kaduk
- Re: [TLS] RFC 7919 on Negotiated Finite Field Dif… Viktor Dukhovni
- Re: [TLS] RFC 7919 on Negotiated Finite Field Dif… Peter Gutmann
- Re: [TLS] RFC 7919 on Negotiated Finite Field Dif… Peter Gutmann
- [TLS] RFC 7919 on Negotiated Finite Field Diffie-… rfc-editor
- Re: [TLS] RFC 7919 on Negotiated Finite Field Dif… Peter Gutmann
- Re: [TLS] RFC 7919 on Negotiated Finite Field Dif… Ryan Hamilton
- Re: [TLS] RFC 7919 on Negotiated Finite Field Dif… Ilari Liusvaara
- Re: [TLS] RFC 7919 on Negotiated Finite Field Dif… Peter Gutmann