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

[Nikos Mavrogiannopoulos <[e-mail]>]

> It seems to me the the recommended Client Behavior and Server Behavior
> has to be simplified and strengthened, in order for the standard to meet
> the security objectives.

Could you elaborate on which security objectives are you referring to?

> All relevant attacks here https://secure-resumption.com/ seem to involve
> a MITM server that chooses bad ServerDHParams for the server key
> exchange message.
>    * Clearly, a MITM server might simply act as if it doesn't support
> the "elliptic_curves" extension. The server does not include a reply to
> the "elliptic_curves" extension in server_hello, so the client will not
> receive any indication of lack of support, until it receives
> server_key_exchange. At this point, the client might decide to terminate
> the handshake if the ServerDHParams aren't acceptable. Checking an
> arbitrary group by means of a binary compare, is only marginally harder
> than checking a named group.
[...]
> A client that requires the use of FFDHE groups MUST perform a binary
> compare of the ServerDHParams against the FFDHE group with the
> corresponding modulus size, and MUST end the handshake with an
> insufficient_security alert if the parameters do not match.

What is the advantage of that proposal? It is more complex, and a security
protocol should strive for simplicity. I see three disadvantages:
1. More bytes to send in a handshake, especially since we are talking about
large groups (that also results to more memory used by implementations
that have to cache those messages until the handshake is finished).
2. Instead of simple maps to known parameters, checks are needed adding more 
space for errors.
3. There are known attacks against the current ServerKeyExchange format which
remain applicable if we go this path (a sufficiently long DH serverkeyexchange
message can be parsed as an ECDH serverkeyexchage).


Furthermore, I'd like to propose to further simplify the message for ServerDHParams
used by the draft, and convert it to a deliberately incompatible format with the 
ServerDHParams as well ServerECDHParams. That way it can be ensured ensure that there
cannot be any mitm taking advantage of the similarities.

regards,
Nikos