Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3)

[Eric Rescorla <[e-mail]>]

On Thu, Mar 27, 2014 at 11:38 PM, Karthikeyan Bhargavan <
[e-mail]> wrote:

>
> Well, the DHE handshake has validation issues: implementations aren't
>
> checking they get sensible inputs.
>
> Fix that, and maybe you have an argument for keeping it. But as it
>
> stands now the insecure resumption attacks are exploiting behavior in
> DHE that isn't fixable without a DOS vector being introduced.
>
>
> In regard to DHE validation, one answer (already proposed on this thread)
> is to use well-known named groups, instead of arbitrary groups. So, rather
> than banning DHE, we could standardise named groups (like named curves) and
> ban the use of arbitrary groups (and arbitrary explicit curves).
>

Note that we could do this for TLS 1.x not just for TLS 1.3, though
obviously we couldn't *require* standardized groups for older
versions for compatibility reasons.

WRT group validation being a DoS vector (a point made by Watson),
the effect of the DoS seems somewhat limited by the fact that it's the
server who selects the group and therefore the client who has to validate
it, so you can't push arbitrary computational load onto some server just by
connecting
to them and forcing it to validate parameters (though of course you can
already do so to some extent by forcing them to do signatures, key
exchanges, etc.)

This isn't to say that DoS of clients isn't a potentially big deal but at
least in the Web context any network attacker can force arbitrary amounts
of computation onto the client just by pushing JS into any HTTP connection
[0]. Outside the Web context, there probably are cases where this would be a
more viable attack, though depending on the cost of validation they
might require the client to also be willing to do a lot of reconnects
automatically in order to be really affected.

-Ekr

[0] And of course in Karthik's attack, the assumption is that the client
would connect to the attack server in any case and so even in an
all HTTPS world, the attacker could shove down arbitrary JS from
his own site.


Still, public key validation remains important for both ECDHE and DHE, and
> essential to prevent insecure resumption-like attacks.
>
> 1. At the end of the first handshake, the finished messages of the
> connections C/A and A/S will be different.
> 2. The outline of the attack rests on the assumption that A might simply
> forward the messages during the second handshake, because all parameters
> are the same, and here the finished messages for C/A and A/S will
> consequently also be the same. Well, they will be if no renegotiation
> indication extension is included. If it is, this will however be different
> for C/A and A/S, and hence result in different finished messages after the
> second handshake as well.
>
>
> Yes, which is why the attack requires 3 handshakes not two. By injecting a
> resumption handshake between 1. and 2. above, the finished messages of C/A
> and A/S can be made the same. I'd be happy to discuss off-list.
>
> Best,
> Karthik
>
>
>
> Am I missing something obvious?
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>