Re: [Cfrg] Security proofs v DH backdoors

[Peter Gutmann <[e-mail]>]

Hanno Böck <[e-mail]> writes:

>This line of debate and all the recently released papers show one very
>concerning thing: We haven't learned how to use Diffie Hellman properly

Well, we have, what it really shows is that there are still implementations
around that use it badly.  As there are for almost everything.

>But why should we have this discussion when we already know DH is on its way
>out? 

It's going to be around for a long, long time, if not forever, for three
reasons.  Firstly, your assumption, which I've heard from others as well,
seems to be based on the browser/web server worldview where you can roll out
an update any time you like to make the server/client do whatever you want it
to.  However, if you look at real-world surveys of TLS traffic, the most
common TLS mode is still 1.0, dating from 1999.  This means that for general
web traffic, not just what Chrome, Firefox, and Edge do, there's at least a
15-year latency for deployment.  In terms of industry bodies, groups like the
PCI council are planning to move to TLS 1.1, from ten years ago, by 2018.
There's no indication of when they'll start looking at TLS 1.2.  Other
industry bodies in the SCADA/embedded space are roughly the same, there's a
gradual move from TLS 1.0 to TLS 1.1 with some mutterings about 1.2 in some
places.

Secondly, DH's replacement, the ECC algorithms, are an absolute non-starter in
any kind of harsh environment.  They're the most brittle crypto you can
possibly deploy, any fault of any kind inevitably ends up leaking the private
key.  I know several industries who, despite its great trendiness, won't touch
the ECC stuff because it's just too brittle to safely use.

Finally, specifically for the Bernstein protocol suite [0] if that's what
you're thinking of for supplanting DH, it's easy enough for someone like
Google to decree that from now on we all have to use X, but many industries
are heavily constrained and regulated and can't just adopt whatever new
algorithm comes along.  Also, hardware support for crypto is almost
universally AES, SHA-1, SHA-2, and sometimes (rarely) some bignum stuff.
You're not going to see any move to TLS 1.3/2.0/whatever-it'll-be-called
outside the web server/client space any time soon there, if ever.

>Chrome already decided to disable it, others will follow. 

That's because Google can decree that from now on we're all going do be doing
what Google wants.  That doesn't work in other industries.

Peter.

[0] No disrespect to Dan et al intended, I'm just using it as a collective
    noun for 25519, 448, ChaCha, Poly1305, etc because I don't know of any
    other collective term for them.