Re: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Fri, 03 April 2015 20:22 UTC

Return-Path: <dkg@fifthhorseman.net>
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 62BDD1A0111 for <tls@ietfa.amsl.com>; Fri, 3 Apr 2015 13:22:41 -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] 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 FmWG9Y1Z6D4l for <tls@ietfa.amsl.com>; Fri, 3 Apr 2015 13:22:39 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAD81A0058 for <tls@ietf.org>; Fri, 3 Apr 2015 13:22:39 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 42BBFF986 for <tls@ietf.org>; Fri, 3 Apr 2015 16:22:36 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 724DF207B2; Fri, 3 Apr 2015 15:22:34 -0500 (CDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: IETF TLS Working Group <tls@ietf.org>
In-Reply-To: <551BBD6F.2070507@cs.tcd.ie>
References: <20150401042731.403F61B256@ld9781.wdf.sap.corp> <551BBD6F.2070507@cs.tcd.ie>
User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu)
Date: Fri, 03 Apr 2015 16:22:34 -0400
Message-ID: <87384harn9.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/9rvRxy11leItZjqYRNHgULA8C6U>
Subject: Re: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08
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: Fri, 03 Apr 2015 20:22:41 -0000

Hi all--

Thanks to Stephen and both Martins for the review.

On Wed 2015-04-01 05:42:07 -0400, Stephen Farrell wrote:
> On 01/04/15 05:27, Martin Rex wrote:
>> I think Stephen might have meant something else.
>> 
>> RFC4492 contains the following explicit prohibition (Section 4, 4th paragr.):
>> 
>>    https://tools.ietf.org/html/rfc4492#section-4
>> 
>>    The client MUST NOT include these extensions in the ClientHello
>>    message if it does not propose any ECC cipher suites. 
>
> Ooh - good catch, I hadn't spotted that. This draft is updating 4492
> though so we can validly change that, but if we're doing so (and I
> guess we are) then it'd be better to be very explicit about it, e.g.
> by adding a sentence saying that we're changing that specific MUST NOT.

I'd be happy to add a sentence to the draft clarifying this point.  If
anyone wants to propose concrete text i'm happy to use it, or i'll try
to come up with something short and sweet.

>> and the above requirement seems to prohibit a non-ECC client from
>> using the named FFDHE parameters through the ECC named curve extension
>> _without_ accompanying ECC cipher suites.
>
> Right. That's the kind of thing I was wondering about.
>
> I'll happily accept the wg's word on this, but to what extent have
> we checked that we're not breaking something with this change in
> semantics. (It's a small, but real, change.)

In practice, i've yet to find a TLS server that chokes when offered
these extensions without any ECC cipher suites.

GnuTLS as a client does not follow this MUST.  You can try it yourself
to connect to any server with something from the 3.x line:

 gnutls-cli --priority NORMAL:-ECDHE-RSA:-ECDHE-ECDSA $SERVER

looking with wireshark, you'll see that there are no ECC ciphersuites,
but the groups and point formats extensions are sent anyway.

I haven't done a full zmap scan of the full ipv4 space, but i've tested
many systems and have not found any servers that abort just because
these extensions are present without an ECC ciphersuite.

      --dkg