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

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 19 August 2016 12:57 UTC

Return-Path: <ilariliusvaara@welho.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 87AB512D758 for <tls@ietfa.amsl.com>; Fri, 19 Aug 2016 05:57:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247] 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 P2FTpkzeXUDL for <tls@ietfa.amsl.com>; Fri, 19 Aug 2016 05:57:10 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id D72AC12D09F for <tls@ietf.org>; Fri, 19 Aug 2016 05:57:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 69C181423C for <tls@ietf.org>; Fri, 19 Aug 2016 15:57:07 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id zebNcwQMt-Vu for <tls@ietf.org>; Fri, 19 Aug 2016 15:57:06 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id E324C21C for <tls@ietf.org>; Fri, 19 Aug 2016 15:57:06 +0300 (EEST)
Date: Fri, 19 Aug 2016 15:56:58 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: tls@ietf.org
Message-ID: <20160819125658.v6t4d6stpo6tk476@LK-Perkele-V2.elisa-laajakaista.fi>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CF416C@uxcn10-5.UoA.auckland.ac.nz>
User-Agent: Mutt/1.6.2-neo (2016-08-08)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/RfGzuVcOV9Do291wcgKiFGXjUoo>
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 12:57:12 -0000

On Fri, Aug 19, 2016 at 12:29:23PM +0000, Peter Gutmann wrote:
> Bodo Moeller <bmoeller@acm.org> writes:
> 
> >Peter, so your complaint is about the lack of support for explicitly
> >specified (non-"named") groups?
> 
> It's the lack of support for DHE unless it's the exact parameters the server
> wants.  At the moment if your implementation wants to use DHE (which pretty
> much all of them do) you have two options:
> 
> 1. Ignore RFC 7919 and perform DHE with several billion devices worldwide.
> 
> 2. Implement RFC 7919 and, unless both client and server happen to choose an
>    appropriate FFDHE parameter set that both sides can agree on, be forced to
>    fall back to the old, unsafe RSA key exchange.

AFAIK, that failure can only happen if at least one of:

- The server is buggy.
- All client-supported FFDHE groups are distrusted or not implemented
  on server (Yes, plural).
- All client-supported FFDHE groups are outside server key size range
  (in which case you probably wouldn't want to try to do DHE with that
  client anyway).


Because otherwise there is always a group choice that works. 


(I would say that 256+257+258 [2k, 3k and 4k] is reasonable set to
implement, 259 and 260 [6k and 8k] are too large).



-Ilari