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
- [TLS] Consensus Call for acceptance of draft-gill… Joseph Salowey (jsalowey)
- Re: [TLS] Consensus Call for acceptance of draft-… Alfredo Pironti
- Re: [TLS] Consensus Call for acceptance of draft-… Nikos Mavrogiannopoulos
- Re: [TLS] Consensus Call for acceptance of draft-… Tapio Sokura
- Re: [TLS] Consensus Call for acceptance of draft-… Watson Ladd
- Re: [TLS] Consensus Call for acceptance of draft-… Nikos Mavrogiannopoulos
- Re: [TLS] Consensus Call for acceptance of draft-… Hubert Kario