Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 16 August 2016 14:55 UTC

Return-Path: <ietf-dane@dukhovni.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 0D70912D881 for <tls@ietfa.amsl.com>; Tue, 16 Aug 2016 07:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 yCpk1iVEx-q6 for <tls@ietfa.amsl.com>; Tue, 16 Aug 2016 07:55:49 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEBE112D1CA for <tls@ietf.org>; Tue, 16 Aug 2016 07:55:49 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B65CA284F26; Tue, 16 Aug 2016 14:55:48 +0000 (UTC)
Date: Tue, 16 Aug 2016 14:55:48 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20160816145548.GQ4670@mournblade.imrryr.org>
References: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CJ9sQ4j4NOfFAMt_sgsIeDhR-08>
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
Reply-To: tls@ietf.org
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: Tue, 16 Aug 2016 14:55:51 -0000

On Tue, Aug 16, 2016 at 10:44:47AM +0000, Peter Gutmann wrote:

> As far as I can see what this text is saying is that if the client can't guess
> in advance which PFS suite/group the server knows about, the server must
> disable use of PFS.  In other words instead of saying "give me a PFS suite,
> preferably with this group", it's saying "give me a PFS suite with exactly
> this group and if you can't do that, don't do PFS".  This seems like a pretty
> awful way to handle things.

The client is expected to send a complete list of *all* the groups
it supports if it supports (any of) the new designated groups.
Which means that clients that support these groups will use only
these groups with servers that likewise suppose these groups, and
will not use FFDHE when the client group list and the server group
list don't overlap (which is seems unlikely).

> In my mind this makes the FFDHE extension so toxic to use that I'd rather not
> support it at all, because it disables PFS unless you're really lucky in
> guessing what the server can do.

There's no guess, the client sends its full list of supported
groups, and the server picks the one it likes.

-- 
	Viktor.