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

[Watson Ladd <[e-mail]>]

On Sat, Oct 25, 2014 at 12:51 PM, Nikos Mavrogiannopoulos
<[e-mail]> wrote:
>> 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).

And 4: session_hash solves the same problem if I understand the
elements of it correctly, and we need it anyway because of this
ambiguity in parsing mentioned above. So do we even need this draft?

>
>
> 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
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin