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

[Watson Ladd <[e-mail]>]

On Fri, Mar 28, 2014 at 10:09 AM, Eric Rescorla <[e-mail]> wrote:
>
>
>
> 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.)

Validating a DH group requires factoring p-1 and determining that it
has a large nonsmooth part, as well as determining p is prime.
This is a lot of work, which is why clients don't do it. (Even if we
demand that p-1 have no prime factors up to 256 bit there isn't a good
way to do that beyond factoring[1]). On my rather nice machine,
running gp and asking it to factor 2^1024-epsilon takes a long time.
The DoS is from one connection, not many.

As for Javascript, web browsers have to deal with scripts running
overtime already. It's a much easier problem.

Sincerely,
Watson Ladd

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