Re: [TLS] FFDHE and SHOULDs on usage

Andrey Jivsov <crypto@brainhub.org> Sat, 18 April 2015 06:31 UTC

Return-Path: <crypto@brainhub.org>
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 463F01A0015 for <tls@ietfa.amsl.com>; Fri, 17 Apr 2015 23:31:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] 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 U3z_9IdID-6G for <tls@ietfa.amsl.com>; Fri, 17 Apr 2015 23:31:03 -0700 (PDT)
Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B3CE1A000F for <tls@ietf.org>; Fri, 17 Apr 2015 23:31:02 -0700 (PDT)
Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-12v.sys.comcast.net with comcast id HJX21q00458ss0Y01JX2t5; Sat, 18 Apr 2015 06:31:02 +0000
Received: from [192.168.1.2] ([71.202.164.227]) by resomta-po-14v.sys.comcast.net with comcast id HJX01q00J4uhcbK01JX1Ww; Sat, 18 Apr 2015 06:31:01 +0000
Message-ID: <5531FA24.4030800@brainhub.org>
Date: Fri, 17 Apr 2015 23:31:00 -0700
From: Andrey Jivsov <crypto@brainhub.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: tls@ietf.org
References: <20150418031052.221221B2A1@ld9781.wdf.sap.corp>
In-Reply-To: <20150418031052.221221B2A1@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1429338662; bh=CA4hoWGls47hJjjaKQ6p9FM0vV7/64diBV5KZgKfxik=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TOp2h6zO0r95Lg6gzUP01edV3uQi99g75YE5kcY0szAUnCLfSE/mX6pP1wTA8oPAK /KFvRYVx+HQwZVuXK4oI6eFhLk0BRLfdSPumtJhEUUmHlQohEuLFnZSLhC1Ts06Hr8 9i+QfAbU+wEmYeZ/KVPPQTmMvKBR+xz8iFfPMggaglClDw1/JWs+fNu0sT8TVbQYFW my1XdGP27bDaNrbkf3WXRVW4PVxZqDeoSKsjl/Z71I4oNaBcxCYGNq9TQnpwN9lYSO rd5vWIqdLcW0y4LCwuE0bT1HHIoPbyxVS5voh6a1P7cOAk8Wrj5utUEQgsHDd2UFZ/ dDofPdDdHRK5w==
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/roWlErbuRoR3OisSiA_fFVjuJ2c>
Subject: Re: [TLS] FFDHE and SHOULDs on usage
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: Sat, 18 Apr 2015 06:31:05 -0000

On 04/17/2015 08:10 PM, Martin Rex wrote:
...
>
> Could we just scrap the "based on xxx preference" nonsense entirely?
>
> The sender of the list sends whatever it sees fit, and the receiver
> of the list has the privilege to pick what ever the receiver believes
> is most appropriate from the receivers point of view.
>
> I never understood why (a) such a silly suggestion was made for
> the ordering of cipher suites in ClientHello and (b) why any TLS server
> implementaion would care for the client's ordering rather than enforcing
> the server preference.  If the client does not want something, it must
> not offer it.  If the server does not want something, it must not pick it.

On ClientHello:

Presumably the existence of ordering of client preferences in the TLS 
spec provides a way for a client to tell that "I really prefer this 
ciphersuite, while I have these others mostly for interoperability". 
There are other benefits.

A server should be able to follow its ordering. One issue with making 
the server rule is that current TLS negotiation mechanism makes a) what 
server supports invisible, b) the ordering of the server set invisible, 
so at least from visibility/troubleshooting/tie-breaking point of view 
there is a benefit to consider the client order.

( It's not too difficult to write a tool that discovers a) and b), but I 
am only aware of tools that report a). ).

One model that can work for a server is to split all supported 
ciphersuites into categories, order by these server categories and by 
ClientHello order within a category. For a simple example consider 
secure and legacy categories. The server prefers any ciphersuite from 
secure category to any from legacy. In more realistic scenarios there 
are more categories and the ordering of categories can be controlled by 
a policy. After the server selects the top category that it prefers, 
inside each category the server selects ciphers according to the client 
order.

This thread is about groups. Here, as Martin said, if the client offers, 
say only ECDHE groups, the client order may not be relevant.

The ordering of the mix of ECDHE+DHE groups can be useful in theory, but 
I expect that most clients will put ECDHE before DHE and servers that 
care about performance order by strength and type, by policy or 
hardcoding these preferences, leaving no say to the client.


>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>