[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PATCH] Re: Logjam mitigation for Wheezy?



Thorsten Glaser <tg@mirbsd.de> writes:

> micah <micah <at> riseup.net> writes:
>
>> Encouraging custom DH groups is not a good idea, as this opens up the
>> triple handshake attack possibility[0].
>> 
>> 0. https://www.secure-resumption.com/ (search for Initial DHE Handshake)
>> <-- details an attack where a server can send custom groups
>
> Interesting, but:
>
> ① This already works, as clients *do* (and do have to) accept those groups.
>
> ② “We instead recommend that a set of well-known good groups be standardized
>   for use in DHE” will open up not only the precomputation problem (though
>   it’s not “as bad” with larger bitsizes), but also the difficulty of selec‐
>   ting one (whom are you going to trust, and NUMS numbers may not actually
>   be good here).

...

> Since their recommendation would require a protocol change anyway, I suggest
> (as I have been doing for a while) that even the DH part of the handshake be
> protected by the server (and, optionally, client) certificate.

This doesn't mean anything, as far as I can tell. Unless you mean "by
the server's signature, which is verified against the public key in the
server's cert", but that is the "secure hash" extensions, which is
orthogonal to fixing ffdhe.

> tl;dr: without a protocol change, clients *are* going to accept custom DH
> groups, so the recommendation to use custom ones currently is not bad. It
> may not be “good” (for 2048+-bit groups), but doesn’t add more harm.

it's true that "secure hash" would fix the triple handshake attack, and
it is a good way to fix it. but clients should not blindly accept custom
groups -- that's irresponsible -- they need to do at least some
checking, or else they shouldn't be presenting "connection secure"
indicators to their users.

the negotiated-ff-dhe draft[0] describes in the "local policy" section some
steps that the clients could/should take to verify the groups and the
offered parameters.

micah

0. https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/


Reply to: