Subject: [TLS] Do we need DH?

From: Watson Ladd <[email-masked]>
Date: Sun, 28 Dec 2014 17:38:11 -0500

Dear all,

I invite you to consider the following interesting sources

http://www.spiegel.de/media/media-35511.pdf
http://www.spiegel.de/media/media-35510.pdf

These show that the NSA has a comparatively easy time exploiting static RSA.

>From this it seems that performance actually matters: the slow speed
of DH exchange compared to ECC explains why ECC, and not DH is
replacing RSA. DH is also being attacked by PHOENIX: I can wild mass
guess that this is batch FFS: I don't know if this has been researched
extensively, and even batch NFS has only an asymptotic analysis.

Given the low usage of the DH handshake, and potential vulnerabilities
(not potential, but certainly not as well understood) should we keep
it in TLS 1.3?

Sincerely,
Watson Ladd

---

From: Fedor Brunner <[email-masked]>
Date: Mon, 29 Dec 2014 13:02:02 +0100

On 28.12.2014 23:38, Watson Ladd wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
> 
> 

http://www.spiegel.de/media/media-35537.pdf

NSA is very carefully watching all crypto, metadata and SIGINT related
development at IETF.

For example:
"New session policy extensions may improve our ability to passively
target two sided communications," says a brief write-up of an IETF
meeting in San Diego on an NSA-internal Wiki.

---

From: Alyssa Rowan <[email-masked]>
Date: Mon, 29 Dec 2014 12:50:25 +0000

> These show that the NSA has a comparatively easy time exploiting 

When SIGINT/LE agencies later steal the keys; absolutely, they would,
as there's no forward-security. (Of course, we're fixing that.) They
also namedrop the Debian key low-entropy issue as a practical attack.

Nice historical graphs. No surprises. (Maybe we could FOIA and get
their statistical trends data to contribute on top of researchers'
existing TLS survey metrics! Might as well be good for something.
Of course, that would mean admitting they're doing mass surveys… <g>)

> From this it seems that performance actually matters: the slow
> speed of DH exchange compared to ECC explains why ECC, and not DH
> is replacing RSA.

Agreed. There was also the issue of >1024-bit DHE field selection,
interoperability, and Java 6.

> DH is also being attacked by PHOENIX: I can wild mass guess that
> this is batch FFS: I don't know if this has been researched

They say PHOENIX is "publicly known" - so maybe it's simpler than that
and something already extensively researched in (what they would call)
the "open source" literature.

(The active attack replacing the field with a trivially-attacked one
that's addressed in TLS 1.2 by the ffdhe draft may be a potential
candidate, although I'm not sure if active attacks fit in the
flowchart there.)

> Given the low usage of the DH handshake, and potential 
> vulnerabilities (not potential, but certainly not as well
> understood) should we keep it in TLS 1.3?

Given the speed penalty, and the ffdhe difficulty, and this - I'd say
no, drop it. Finite-field DHE is worse than good ECDHE (and/or X25519).

(Non-ephemeral key agreement definitely needs to go, too; didn't Eric
already call for consensus on that?)

- -- 
/akr

---

From: Yoav Nir <[email-masked]>
Date: Mon, 29 Dec 2014 19:42:49 +0200

I don’t know of any reason besides legacy compatibility to support regular DH. In IKE it is necessary, because DH (and forward secrecy) was mandatory from the start. In TLS PFS has been defined forever, but it only became popular fairly recently, when ECDHE was already defined and implemented.

So speaking only for myself, I have no plan to add FF DH in my TLS implementation. I’ve said as much when TLS was considering DKG’s draft. 

Yoav

> On Dec 29, 2014, at 12:38 AM, Watson Ladd <[email-masked]> wrote:
> 
> Dear all,
>

---

From: Tapio Sokura <[email-masked]>
Date: Tue, 30 Dec 2014 09:23:22 +0200

> (not potential, but certainly not as well understood) should we keep

I'm a bit vary of putting all eggs in the same basket (here ECDH). Why
not allow the pre-parametrised form of DH described in
draft-ietf-tls-negotiated-ff-dhe in TLS 1.3 and drop the current way of
server sending the explicit group parameters?

With regards to all eggs being in the same basket, AES is also something
that really should have a realistic alternative standardized and
deployed _before_ (/if) AES is broken. Like SHA-3 is coming around the
corner while SHA-2 is still well alive and kicking.

  Tapio

---

From: Brian Smith <[email-masked]>
Date: Tue, 30 Dec 2014 00:34:47 -0800

Tapio Sokura <[email-masked]> wrote:
> I'm a bit vary of putting all eggs in the same basket (here ECDH).

The main problems with FF-DHE as a fallback mechanism for if/when
ECC-DH is borken are (1) It seems unlikely that the ECC-DH problem
will be solved without solving the FF-DH problem too, (2) Even if that
were to happen, FF-DH with acceptable security parameters would result
in unacceptable performance. Consequently, I don't think it makes
sense to consider FF-DH a reasonable fallback for ECC-DH.

Cheers,
Brian

---

From: Maarten Bodewes <[email-masked]>
Date: Tue, 30 Dec 2014 15:40:49 +0100

> corner while SHA-2 is still well alive and kicking.

Although it doesn't invalidate the rest of your argument, the SHA-3
competition was started up when SHA-1 was under significant attack. It
wasn't clear at that time if SHA-2 would be affected as well. By now no
SHA-1 collisions have been found, and - more importantly - the attacks on
SHA-1 don't seem to translate to SHA-2. This is probably a main reason why
at the time of writing SHA-3/Keccak is still not finalized as a standard
(although I expect it will be soon).

The main problem with ECDH is that it can be executed without performing
enough verification on the parameters or public key. But those issues are
present for DH as well. So in my opinion the main thing speaking for DH is
it's relative simplicity of implementation compared to ECDH (for some
libraries ECDH is slower than DH for comparative levels of security for
this reason alone!).

Regards,
Maarten