Re: [Cfrg] Security proofs v DH backdoors

[Ilari Liusvaara <[e-mail]>]

On Wed, Oct 26, 2016 at 04:32:49AM +0000, Peter Gutmann wrote:
> Ilari Liusvaara <[e-mail]> writes:
> 
> >I think there was one TLS implementation that tries to verify the groups sent
> >(of course, not all can be verified, even if those aren't maliscously
> >constructed).
> 
> (Hey, I've got to get the maximum mileage out of this one :-).  LTS has
> already foiled attacks that postdate its publication, so you know it's a good
> thing).

Unfortunately, LTS is a non-starter as web browsers are concerned. And
it is pretty much non-starter as far as everything else is concerned.

It also does not fix the reasons why web browers are first moving DHE
behind fallback and now deimplementing it entierely (because you can't
realistically reject any DHE parameters, but if you dont reject insecure
ones, you get serious security problems. Catch 22.).

Heck, the web browser vendors don't seem to be interested in DHE in TLS
1.3, even after -15 fixed the "DHE downnegotiation" problem (TLS 1.3
draft 15 and forward are not affected by the major trouble DHE causes
in prior TLS versions).

And the "backup" of DHE is unfortunately RSA key exchange, which is
well-known to be very broken (serious security problems).

So the only asymmetric key exchange that actually works is ECDHE
(P-256 or X25519).


-Ilari