Re: [TLS] FFDHE and SHOULDs on usage

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
>