Re: [TLS] Consensus Call for acceptance of draft-gillmor-tls-negotiated-dl-dhe-02

Tapio Sokura <tapio.sokura@iki.fi> Tue, 24 June 2014 03:12 UTC

Return-Path: <tapio.sokura@iki.fi>
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 3E3311B2817 for <tls@ietfa.amsl.com>; Mon, 23 Jun 2014 20:12:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.879
X-Spam-Level:
X-Spam-Status: No, score=0.879 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 RncVVlcWCbs0 for <tls@ietfa.amsl.com>; Mon, 23 Jun 2014 20:12:15 -0700 (PDT)
Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C92A1B2813 for <tls@ietf.org>; Mon, 23 Jun 2014 20:12:15 -0700 (PDT)
Received: from woodstock.owlhill.net (a88-113-163-188.elisa-laajakaista.fi [88.113.163.188]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 8066D40016 for <tls@ietf.org>; Tue, 24 Jun 2014 06:12:10 +0300 (EEST)
Received: from [IPv6:2001:14b8:14e:1:a592:1147:e7f2:38ee] (unknown [IPv6:2001:14b8:14e:1:a592:1147:e7f2:38ee]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by woodstock.owlhill.net (Postfix) with ESMTP id 99A9E9092CA for <tls@ietf.org>; Tue, 24 Jun 2014 06:12:10 +0300 (EEST)
Message-ID: <53A8EC80.3060309@iki.fi>
Date: Tue, 24 Jun 2014 06:12:00 +0300
From: Tapio Sokura <tapio.sokura@iki.fi>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: tls@ietf.org
References: <C5353235-60DA-4193-BEE5-38FBD0D531AE@cisco.com>
In-Reply-To: <C5353235-60DA-4193-BEE5-38FBD0D531AE@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KBRauEz_i08ZmWtYyPkSZ0YRRRQ
Subject: Re: [TLS] Consensus Call for acceptance of draft-gillmor-tls-negotiated-dl-dhe-02
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: Tue, 24 Jun 2014 03:12:18 -0000

Hello,

On 23.6.2014 8:27, Joseph Salowey (jsalowey) wrote:
> The chairs would like to get the sense of the WG on adopting
> as a WG document:
> 
> http://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-02

Looks good, I support this.

A small editorial note, the middle of section 1.2 should include the
abbreviation ECDHE immediately in the sentence where it is spelled out,
for example "TLS also supports elliptic-curve-based Diffie Hellman
ephemeral (ECDHE) key exchanges, but this document does not discuss
their use."

My layman view on section 5.1 is that I don't think the server needs to
indicate it's support of named DHE groups if the negotiated ciphersuite
doesn't use them. The client should not make any conclusions about the
support of named DHE groups on the server now or in the future, if the
server chooses a non-DHE group. Consequently the client should always
include the extension on every ClientHello, if the client is willing to
use those groups.

A good thing in including a 1024 DHE group (section 5.2) in the named
group list would be that the client would not need to verify that the
group parameters are secure when using a small group. But then again a
modern server or client that comes to support this extension will with
very high probability support the stronger groups anyway, so I don't
think there is a need for weak groups in the spec. If we think of the
strengths of the groups in the draft, 112-125-150-175-192 bits, do we
even need the 2432 bit group, it's so close to a 3072 bit group?

  Tapio