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

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

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. All the draft says is that the server shouldn't 
send specially formatted server_key_exchange messages to non-compatible 
clients, which makes sense.-


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

Perhaps I wasn't clear. This isn't a second situation. It is just a 
second way the server might interpret the SAME ambiguous situation.


> 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.)