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

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

On 2014-10-26 08:09, Nikos Mavrogiannopoulos wrote:
> To be honest I don't see that to be a lot more complex, and the complexity
> on the same level as supporting ECDH with named groups and arbitrary groups,
> which was deemed reasonable for ECDH. Consistency (with ECDH) is also another
> reason to keep the code paths separated.

Another thing about this rule:

>    A compatible TLS server that receives the NamedCurve extension with
>    FFDHE codepoints in it, and which selects an FFDHE ciphersuite MUST
>    select one of the offered groups and indicates the choice of groups
>    to the client by sending a specially-formatted ServerDHParams as
>    described below.

Suppose a client offers both ECDHE and FFDHE cipher suites, and does 
send the NamedCurve extension, but with no identifiers the server 
recognizes as FFDHE groups, but with a few identifiers the server 
doesn't recognize at all.

How is the server supposed to tell if:
   1. The client doesn't support named FFDHE groups at all and expects 
the arbitrary encoding of FFDHE server key exchange messages, or
   2. The client supports only a few named FFDHE groups defined in a 
later revision of the standard that the server hasn't yet implemented, 
meaning the server ideally MUST NOT use the arbitrary encoding of FFDHE 
groups, but rather pick other cipher suites?

This is a dilemma that implementors might decide to circumvent in 
complex and undesirable ways.