Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt

Henrick Hellström <henrick@streamsec.se> Mon, 27 October 2014 11:37 UTC

Return-Path: <henrick@streamsec.se>
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 D87F01A90B7 for <tls@ietfa.amsl.com>; Mon, 27 Oct 2014 04:37:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.25
X-Spam-Level:
X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 JDC4cjvsW_WM for <tls@ietfa.amsl.com>; Mon, 27 Oct 2014 04:37:04 -0700 (PDT)
Received: from vsp5.ballou.se (vsp5.ballou.se [91.189.40.84]) by ietfa.amsl.com (Postfix) with SMTP id C03391A9095 for <tls@ietf.org>; Mon, 27 Oct 2014 04:37:03 -0700 (PDT)
Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp5.ballou.se (Halon Mail Gateway) with ESMTP; Mon, 27 Oct 2014 12:37:01 +0100 (CET)
Received: from [192.168.0.195] (c-21cfe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.207.33]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 32B481DE4C; Mon, 27 Oct 2014 12:37:01 +0100 (CET)
Message-ID: <544E2E5D.4000805@streamsec.se>
Date: Mon, 27 Oct 2014 12:37:01 +0100
From: Henrick Hellström <henrick@streamsec.se>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com> <5438B82B.6090600@fifthhorseman.net> <544BD3BF.9030702@streamsec.se> <1682594903.63043.1414266713793.JavaMail.zimbra@redhat.com> <544C1BC3.5060204@streamsec.se> <1749574094.84536.1414307373087.JavaMail.zimbra@redhat.com> <544E0682.30804@streamsec.se> <1414405551.2543.8.camel@dhcp-2-127.brq.redhat.com> <544E254A.3020501@streamsec.se> <1414408020.2543.13.camel@dhcp-2-127.brq.redhat.com>
In-Reply-To: <1414408020.2543.13.camel@dhcp-2-127.brq.redhat.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DOeUbaloFBQV21HeQBSz1PqqyyY
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: henrick@streamsec.se
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: Mon, 27 Oct 2014 11:37:06 -0000

On 2014-10-27 12:07, Nikos Mavrogiannopoulos wrote:
> We may be referring to different versions of the draft. The current
> draft says:
> "If the extension is present, none of the client's offered groups are
>     acceptable by the server, and none of the client's proposed non-FFDHE
>     ciphersuites are acceptable to the server, the server SHOULD end the
>     connection with a fatal TLS alert of type insufficient_security."
>
> This does explicitly prohibit the server to negotiate an FFDHE cipher
> suite if the extension is present.

OK, I stand corrected, I didn't interpret that paragraph that way. It 
starts with

>    If a compatible TLS server receives a NamedCurves extension from a
>    client that includes any FFDHE groups


...so I interpreted the whole paragraph as referring to extensions the 
server is able to recognize as including BOTH named elliptic curves AND 
named ffdhe groups. If it really says that a Named FFDHE compatible 
server MUST NOT negotiate DHE cipher suites with clients that implement 
RFC 4492, but not the Named FFDHE standard, that should be stated 
explicitly.

It does however strike me as odd that, as a consequence, a named FFDHE 
compatible server, would still be allowed to negotiate DHE cipher suites 
with legacy clients that do not even implement RFC 4492, but not with 
legacy clients that implement DHE in the exact same way, but also 
support a few weak elliptic curves.