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

[Nikos Mavrogiannopoulos <[e-mail]>]

On Mon, 2014-10-27 at 11:58 +0100, Henrick Hellström wrote:
> On 2014-10-27 11:25, Nikos Mavrogiannopoulos wrote:
> > On Mon, 2014-10-27 at 09:46 +0100, Henrick Hellström wrote:
> >> 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.
> 
> That is NOT what the draft says. The draft does NOT prohibit the server 
> to negotiate an FFDHE cipher suite, when negotiating with a 
> non-compatible client.

We may be referring to different versions of the draft. The current
draft says:
"If the extension is present, none of the client's offered groups are
   acceptable by the server, and none of the client's proposed non-FFDHE
   ciphersuites are acceptable to the server, the server SHOULD end the
   connection with a fatal TLS alert of type insufficient_security."

This does explicitly prohibit the server to negotiate an FFDHE cipher
suite if the extension is present.

> > 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.
> FWIW, the real problem here is RFC 4492. There was no ambiguity in TLS 
> 1.0, because the ServerKeyExchange could only contain two kinds of 
> messages, one with two large integers (a ServerRSAParams) or one with 
> three large integers (a ServerDHParams). RFC 4492 introduced the 
> ambiguity. Can anyone think of a way to fix it, without forcing Named 
> FFDHE compatible servers to negotiate RSA cipher suites instead of DHE 
> cipher suites with legacy clients? Is that even a good idea? (That was a 
> rhetorical question.)

A way to fix that for the ffdhe draft would be to introduce a two-byte
type that is on purpose large (eg. values like 0xff 0xfa).

regards,
Nikos