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

[Nikos Mavrogiannopoulos <[e-mail]>]

On Mon, 2014-10-27 at 14:20 -0400, Daniel Kahn Gillmor wrote:
> On Mon 2014-10-27 07:37:01 -0400, Henrick Hellström wrote:
> > It does however strike me as odd that, as a consequence, a named FFDHE 
> > compatible server, would still be allowed to negotiate DHE cipher suites 
> > with legacy clients that do not even implement RFC 4492, but not with 
> > legacy clients that implement DHE in the exact same way, but also 
> > support a few weak elliptic curves.
> 
> hm, yes, i agree that this is a bad outcome, and as of -02 that does
> appear to be the consequence of the draft.  Thanks for pointing this
> out, Henrick.
> 
> To be clear, i think the problem is:
> 
>  * a compatible server might see a client send a DHE ciphersuite and the
>    NamedCurves extension, but with at least one identified NamedCurve
>    that the server doesn't know.
> 
>  * In this case, the server cannot distinguish the following two peers:
> 
>     A) the client implements this draft, but only implements an unusual
>        FFDHE that the server has never heard of.
> 
>     B) the client does not implement with this draft and happens to
>        implement an elliptic curve that the server has never heard of.
> 
>  * The right logic here is that the server SHOULD NOT select DHE for
>    client A, but MAY select DHE for client B, as when interoperating
>    with any other legacy client implementation.  But the server can't
>    distinguish between these cases.

I wouldn't distinguish between these two cases. If the goal is to
promote interoperability, the DHE ciphersuites should not be negotiated
by a compliant server if there are no curves advertised by the client.

Otherwise in client B case, if the server proceeds with negotiating DHE,
the issue that the draft tries to solve reappears, i.e., a broken
session because the DH parameters presented to client for some reason
are not acceptable by the client (e.g., a java client which only
supports 1024-bit parameters).

> I think there needs to be explicit signalling from the client that it
> understands known FFDHE groups, so that a server can distinguish between
> these cases.
> I see three ways to achieve this goal:

I'd add that:
3) Keep the currently defined behavior (i.e., prefer any other
ciphersuite to DHE if the peers share no common groups).

regards,
Nikos