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

[Henrick Hellström <[e-mail]>]

On 2014-10-25 21:51, Nikos Mavrogiannopoulos wrote:
>> It seems to me the the recommended Client Behavior and Server Behavior
>> has to be simplified and strengthened, in order for the standard to meet
>> the security objectives.
>
> Could you elaborate on which security objectives are you referring to?

Second paragraph of section 6.3 Arbitrary groups:

>    Note that in several known attacks against TLS and SSL
>    [SECURE-RESUMPTION] [CROSS-PROTOCOL] [SSL3-ANALYSIS], a malicious
>    server uses a deliberately broken FFDHE group to impersonate the
>    client to a different server."


> What is the advantage of that proposal? It is more complex, and a security
> protocol should strive for simplicity.

In my view, the current draft leads to a lot more complex 
implementations, compared to my proposal.

You get complexity for two major reasons:
   * When adding new abilities in a manner that is not backwards 
compatible by design.
   * When balancing security requirements against interoperability 
requirements, without clear indications in the standards how these 
requirements should be balanced.

The problem a client faces, is that if it supports TLS 1.0 through TLS 
1.2, it will have to be prepared to deal with servers sending arbitrary 
FF DHE groups anyway. While I agree the ambiguity of the 
server_key_exchange message is a concern, implementing the draft-02 
doesn't resolve that ambiguity. Implementing TLS 1.3 and dropping 
support for older versions might be solution, but that is not going to 
happen any time soon.

Consequently, I would argue that a recommendation that ECDHE should only 
use named curves, and FF DHE only use standard groups encoded as 
arbitrary groups, would be closer to reality, lead to greater security 
at the expense of less interoperability issues, and make both server 
implementations and client implementations (that require backwards 
compatibility with older peers) *less* complex.