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

[Nikos Mavrogiannopoulos <[e-mail]>]

On Mon, 2014-10-27 at 09:46 +0100, Henrick Hellström wrote:
> 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

All the server needs to know is the common FFDHE groups they support.
And that it apparent in that case. None.

If they have no common groups the server SHOULD NOT negotiate DHE
according to the current draft, so no dilemma here.

>    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?

I think the situation is similar as above. The intersection of the
supported FFDHE groups is empty, thus according to the
draft-ietf-tls-negotiated-ff-dhe a compliant server should not select
the DHE ciphersuites at all. If he selected DHE ciphersuites, it is a
legacy server that doesn't support the draft. So for the server, the
decisions are straightforward as far as I understand.

A client though will have to decide on whether a legacy server is seen,
or a compliant to ffdhe draft, based on the format of ServerKeyExchange.
That's why I suggested to make them sufficiently distinct.

regards,
Nikos