Subject: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt

From: [email-masked]
Date: Mon, 01 Jun 2015 15:50:57 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the IETF.

        Title           : Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS
        Author          : Daniel Kahn Gillmor
	Filename        : draft-ietf-tls-negotiated-ff-dhe-10.txt
	Pages           : 26
	Date            : 2015-06-01

Abstract:
   Traditional finite-field-based Diffie-Hellman (DH) key exchange
   during the TLS handshake suffers from a number of security,
   interoperability, and efficiency shortcomings.  These shortcomings
   arise from lack of clarity about which DH group parameters TLS
   servers should offer and clients should accept.  This document offers
   a solution to these shortcomings for compatible peers by using a
   section of the TLS "EC Named Curve Registry" to establish common
   finite-field DH parameters with known structure and a mechanism for
   peers to negotiate support for these groups.

   This draft updates TLS versions 1.0 [RFC2246], 1.1 [RFC4346], and 1.2
   [RFC5246], as well as the TLS ECC extensions [RFC4492].

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-negotiated-ff-dhe-10

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 1 Jun 2015 16:02:24 -0700

Alternative suggestion: DHE diediedie

Is there really a compelling reason to keep it around? I expect the
response is going to be "What if there's some catastrophic failure of ECC?"
but if that really happens, can't we just temporarily forego forward
secrecy rather than further complecting TLS with a backup we probably won't
need?

On Mon, Jun 1, 2015 at 3:50 PM, <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
Tony Arcieri

---

From: Hubert Kario <[email-masked]>
Date: Tue, 02 Jun 2015 14:54:11 +0200

> secrecy rather than further complecting TLS with a backup we probably won't

as it was pointed out many times: adding support for this extension and groups 
to implementations that already support FF DHE is rather trivial, adding 
support for ECC is complex (both because of compexity of ECC and because it's 
a completely new set of algorithms)

This allows us to move away from defaulting to 1024bit or 2048bit on server 
side in fear of breaking, for example, Java based clients

> >  This draft is a work item of the Transport Layer Security Working Group
> > 
> > of the IETF.
> > 
> >         Title           : Negotiated Finite Field Diffie-Hellman Ephemeral
> > 
> > Parameters for TLS
> > 

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 2 Jun 2015 23:00:14 -0700

> side in fear of breaking, for example, Java based clients

Hi there,

Some context. I typically don't go "full blowhard". That's something I
actively avoid. But I feel it's warranted here.

I am responsible for the external ciphersuites configuration for a site
that moves over a hundred million dollars per day supporting millions of
users.

I have also spent what I feel are undue amounts of my own time (probably at
least 10 hours in the past month) chasing down DHE problems with Java
stacks, trying to solve problems where entire language ecosystems had a
total outage of their packaging systems due to Java DHE issues.

My opinion is DHE diediedie. I am sorry if I didn't participate when it was
"pointed out many times". But this is a draft, and I feel like now isn't an
undue time to make a counterargument?

Even having DHE enabled when 4096-bit DHE ciphersuites are configured
completely blocks Java from completing a TLS handshake. Depending on what
Java version, having 2048-bit DHE ciphersuites enabled does the same thing.

There were two solutions: get the upstream service to eliminate the
problematic ciphersuites, or have the Java client disable DHE. In hopes of
getting traffic flowing again, I have told both sides to shut off DHE, and
as soon as either side complied, the handshake could complete.

What problem do you think this draft is solving? How will it fix older Java
clients?

So far my experience has been that shutting off DHE solves the problem. If
you want ECC, use BouncyCastle as your JCE provider.

Anyway, I am responsible for supporting legacy Java 7 (and Java 6!) clients
and my opinion is that DHE is actively detrimental to the TLS ecosystem,
*especially* where Java is involved.

So I am very, very, very confused about what argument you're trying to make
about Java here. As far as I'm concerned the *only* workable solution for
older Java clients is to shut DHE off.

Can you please explain to me where in this draft I can locate the part
about how it will help older Java clients better participate in the TLS
ecosystem, because I can't find it.

-- 
Tony Arcieri

---

From: Yuhong Bao <[email-masked]>
Date: Tue, 2 Jun 2015 23:15:17 -0700

These older versions of Java don't support FF-DHE, and the server can send a different weaker DHE key to older clients.

________________________________
> From: [email-masked] 
> Date: Tue, 2 Jun 2015 23:00:14 -0700 
> To: [email-masked] 
> CC: [email-masked] 
> Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt 
> 
> On Tue, Jun 2, 2015 at 5:54 AM, Hubert Kario 
> <[email-masked]<mailto:[email-masked]>> wrote: 
> that moves over a hundred million dollars per day supporting millions 
> of users. 
> 
> I have also spent what I feel are undue amounts of my own time 
> (probably at least 10 hours in the past month) chasing down DHE 
> problems with Java stacks, trying to solve problems where entire 
> language ecosystems had a total outage of their packaging systems due 
> to Java DHE issues. 
> 
> My opinion is DHE diediedie. I am sorry if I didn't participate when it 
> was "pointed out many times". But this is a draft, and I feel like now 
> isn't an undue time to make a counterargument? 
> 
> completely blocks Java from completing a TLS handshake. Depending on 
> what Java version, having 2048-bit DHE ciphersuites enabled does the 
> same thing. 
> 
> problematic ciphersuites, or have the Java client disable DHE. In hopes 
> of getting traffic flowing again, I have told both sides to shut off 
> DHE, and as soon as either side complied, the handshake could complete. 
> 
> What problem do you think this draft is solving? How will it fix older 
> Java clients? 
> 
> So far my experience has been that shutting off DHE solves the problem. 
> If you want ECC, use BouncyCastle as your JCE provider. 
> 
> Anyway, I am responsible for supporting legacy Java 7 (and Java 6!) 
> clients and my opinion is that DHE is actively detrimental to the TLS 
> ecosystem, *especially* where Java is involved. 
> 
> So I am very, very, very confused about what argument you're trying to 
> make about Java here. As far as I'm concerned the *only* workable 
> solution for older Java clients is to shut DHE off. 
> 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 2 Jun 2015 23:16:50 -0700

Here is what I've observed:

Logjam made a lot of people aware of the problem of weak D-H groups.
Because of that, people have been trying to enable stronger D-H groups.

Unfortunately, exactly as you've pointed out, legacy clients are
incompatible with these stronger D-H groups. For legacy Java clients, it
catastrophically completely prevents the TLS handshake from succeeding if
any such ciphersuite is even present in the ServerHello.

My experience has been, and correct me if I'm wrong, that the only two ways
to fix this are for the Java client to disable all DHE ciphersuites, or for
the server to not offer them. Depend on the Java version, DHE with 2048-bit
keys can break it, and for newer versions of Java, the problem persists for
4096-bit DHE.

The result I've seen has been people hardening their DH groups in response
to Logjam, and inadvertently breaking Java clients... for more than one
entire language ecosystem temporarily.

On Tue, Jun 2, 2015 at 11:00 PM, Tony Arcieri <[email-masked]> wrote:

> I have also spent what I feel are undue amounts of my own time (probably
> at least 10 hours in the past month) chasing down DHE problems with Java
> make about Java here. As far as I'm concerned the *only* workable solution
> for older Java clients is to shut DHE off.
>

-- 
Tony Arcieri

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 2 Jun 2015 23:20:03 -0700

On Tue, Jun 2, 2015 at 11:15 PM, Yuhong Bao <[email-masked]>
wrote:

> These older versions of Java don't support FF-DHE, and the server can send
> a different weaker DHE key to older clients.

As I have "pointed out many times", yes there are ways to work around these
problems, but DHE hardening is presently actively breaking TLS ecosystem.
And for what?

Finite field D-H is taking attention away from ECC, and I think ECC is
clearly the future. What good reason is there for continuing to support it
instead of focusing on ECDH?

I want a TLS ecosystem with less workarounds, less errata, and less
complexity. I see no reason to keep DHE around.

-- 
Tony Arcieri

---

From: Geoffrey Keating <[email-masked]>
Date: 02 Jun 2015 23:32:11 -0700

> ecosystem, because I can't find it.

It's covered in section 4:

   If at least one FFDHE ciphersuite is present in the client
   ciphersuite list, and the Supported Groups extension is either absent
   from the ClientHello entirely or contains no FFDHE groups (i.e. no
   codepoints between 256 and 511 inclusive), then the server knows that
   the client is not compatible with this document.  In this scenario, a
   server MAY select a non-FFDHE ciphersuite, or MAY select an FFDHE
   ciphersuite and offer an FFDHE group of its choice to the client as
   part of a traditional ServerKeyExchange.

In this case, and I think most of the time, a server should choose the
first of the two MAYs: offer a non-FFDHE ciphersuite.  This has the
effect of shutting FFDHE off for those older clients but allows you to
continue to offer stronger FFDHE to newer clients (if they for some
reason won't do ECDHE).

The old-client compatibility story with this draft is quite strong.
Alas the old-server compatibility story is not so strong; a new client
with an old server might get proposed an insecurely small FFDHE field,
and have to reject it and reconnect.

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 2 Jun 2015 23:35:46 -0700

On Tue, Jun 2, 2015 at 11:32 PM, Geoffrey Keating <[email-masked]> wrote:

>    from the ClientHello

Unless I'm mistaken, unless you configure the jdk.tls.disabledAlgorithms
property explicitly (with e.g. "DHE keySize > 2048"), Java clients are
aborting *before* they send the ClientHello. Please let me know if you're
seeing otherwise. I could be mistaken and perhaps there's a server-side
workaround for this that isn't "disable all DHE ciphersuites". But this is
what I've personally observed and have been advising people about.

I'm not saying it can't be fixed with additional configuration/errata/etc,
I'm arguing that it's *breaking clients in the field right now*

tl;dr: I am seeing *widespread TLS breakages* because of this resulting in
*huge outages* for Java clients

-- 
Tony Arcieri

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 2 Jun 2015 23:37:24 -0700

The error is specifically:

Java::JavaLang::RuntimeException: Could not generate DH keypair

-- 
Tony Arcieri

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 2 Jun 2015 23:43:48 -0700

A more typical Java stack trace for this problem:

Caused by: java.lang.RuntimeException: Could not generate DH keypair
    at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:106)
    at
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:556)

On Tue, Jun 2, 2015 at 11:37 PM, Tony Arcieri <[email-masked]> wrote:

>> I'm not saying it can't be fixed with additional
>> configuration/errata/etc, I'm arguing that it's *breaking clients in the
>> field right now*
>>
>> tl;dr: I am seeing *widespread TLS breakages* because of this resulting
>> in *huge outages* for Java clients
>>
>> --
>> Tony Arcieri
>>
>
>
>
> --
> Tony Arcieri
>

-- 
Tony Arcieri

---

From: Yuhong Bao <[email-masked]>
Date: Tue, 2 Jun 2015 23:52:07 -0700

The client don't receive the ServerKeyExchange message containing the DHE key at all until after they sent the ClientHello.

> From: [email-masked] 
> Date: Tue, 2 Jun 2015 23:35:46 -0700 
> To: [email-masked] 
> CC: [email-masked] 
> On Tue, Jun 2, 2015 at 11:32 PM, Geoffrey Keating 
> <[email-masked]<mailto:[email-masked]>> wrote: 
> Unless I'm mistaken, unless you configure the 
> jdk.tls.disabledAlgorithms property explicitly (with e.g. "DHE keySize 
>> 2048"), Java clients are aborting *before* they send the ClientHello. 
> Please let me know if you're seeing otherwise. I could be mistaken and 
> perhaps there's a server-side workaround for this that isn't "disable 
> all DHE ciphersuites". But this is what I've personally observed and 
> have been advising people about. 
> 
> configuration/errata/etc, I'm arguing that it's *breaking clients in 
> the field right now* 
>

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 2 Jun 2015 23:52:36 -0700

Yes sorry I meant ClientKeyExchange...

But can you explain to me how this solves the problem for legacy clients?

On Tue, Jun 2, 2015 at 11:52 PM, Yuhong Bao <[email-masked]>
wrote:

> The client don't receive the ServerKeyExchange message containing the DHE
> key at all until after they sent the ClientHello.
>

-- 
Tony Arcieri

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 2 Jun 2015 23:53:31 -0700

Perhaps you have a test case with a Java 6 or 7 client using the Sun/Oracle
JCE provider? What *actually* happens there?

-- 
Tony Arcieri

---

From: Yuhong Bao <[email-masked]>
Date: Tue, 2 Jun 2015 23:54:50 -0700

The idea is that the server can send a different weaker DHE key in the ServerKeyExchange, or not use DHE suites at all.

> From: [email-masked] 
> Date: Tue, 2 Jun 2015 23:52:36 -0700 
> To: [email-masked] 
> CC: [email-masked]; [email-masked] 
> 
> On Tue, Jun 2, 2015 at 11:52 PM, Yuhong Bao 
> <[email-masked]<mailto:[email-masked]>> wrote: 
> The client don't receive the ServerKeyExchange message containing the 
> DHE key at all until after they sent the ClientHello. 
> 
>> From: [email-masked]<mailto:[email-masked]> 
>> To: [email-masked]<mailto:[email-masked]> 
>> CC: [email-masked]<mailto:[email-masked]> 
> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> 
> wrote: 
>> [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/tls 
> 
> 
> 
> 
> -- 
> Tony Arcieri

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 3 Jun 2015 00:00:07 -0700

So this is the exact problem I've been talking about.

After this draft is actually implemented in all TLS servers everywhere,
server operators can add Java-specific errata to their configuration to
work around the fundamental problem that DHE is breaking Java TLS
handshakes.

Or you can just add the Java property I cited above. Which is total oddball
errata. Nobody should have to worry about jdk.tls.disabledAlgorithms="DHE
keySize > 2048"

This is just adding to the "headache" of maintaining a modern TLS stack.

I'll freely admit I just made mistakes trying to diagnose this problem but
as a practitioner I seriously don't care about supporting these things and
want them to just go away and for TLS handshakes to just work and not
spontaneously break because of misconfigurations.

I don't see how adding more complexity fixes the problem.

I just want DHE to diediedie.

Perhaps someone can explain how keeping DHE around is actually beneficial
in any way whatsover? Right now it's just giving me a headache and making
me angry.

On Tue, Jun 2, 2015 at 11:54 PM, Yuhong Bao <[email-masked]>
wrote:

> The idea is that the server can send a different weaker DHE key in the
> ServerKeyExchange, or not use DHE suites at all.
>
> >> [email-masked]<mailto:[email-masked]>

-- 
Tony Arcieri

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 3 Jun 2015 00:33:07 -0700

Here's a real-world example of what I've just been going through with
regard to Java and DHE:

https://github.com/jruby/jruby/issues/2872

Note the ticket is about the general problem, and in the course of it there
have been multiple manifestations of the problem.

On Wed, Jun 3, 2015 at 12:00 AM, Tony Arcieri <[email-masked]> wrote:

> Or you can just add the Java property I cited above. Which is total
> oddball errata. Nobody should have to worry about jdk.tls.disabledAlgorithms="DHE
> keySize > 2048"
>

-- 
Tony Arcieri

---

From: Dave Garrett <[email-masked]>
Date: Wed, 3 Jun 2015 04:05:47 -0400

> in any way whatsover? Right now it's just giving me a headache and making

People want a backup to deal with mistrust of ECC curves and general paranoia. Though, with issues this bad, yeah, killing it seems like a sensible option. I don't think the paranoia is unwarranted, however.

> I don't see how adding more complexity fixes the problem.

Well... here's a way it could:
1) Deprecate/prohibit all "DH(E)_*" cipher suites
2) Create a new set of "FFDHE_*" cipher suites to replace them that only allow strong groups (3072+)

I'm not saying this is the best idea, but it is _an_ idea. ;)

Dave

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 3 Jun 2015 08:07:36 +0000

Tony Arcieri <[email-masked]> writes:

>server operators can add Java-specific errata to their configuration to work
>around the fundamental problem that DHE is breaking Java TLS handshakes.

You've got that exactly reversed, it's not "DHE is breaking Java handshakes",
it's "(Sun/Oracle's) Java is breaking DHE handshakes".  Their Java's broken
handling of DLP key sizes has been a known problem for years (and years, and
years, and years).  First Sun and then Oracle have chosen to ignore the
problem despite repeated complaints by users over a long period of time.  It
is not the IETF's job to fix a particular vendor's broken, buggy code.

>I just want DHE to diediedie.

I just want Sun/Oracle Java's broken handling of this to diediedie.  Let's see
which one happens first.

Peter.

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 3 Jun 2015 01:20:15 -0700

On Wed, Jun 3, 2015 at 1:05 AM, Dave Garrett <[email-masked]> wrote:

> People want a backup to deal with mistrust of ECC curves and general
> paranoia.

I'll refer to my first response to this thread:

On Mon, Jun 1, 2015 at 4:02 PM, Tony Arcieri <[email-masked]> wrote:

> I expect the response is going to be "What if there's some catastrophic
> failure of ECC?"
>

The reality is DHE hardening attempts are breaking Java 6, 7, and in some
cases 8 clients from negotiating TLS connections in the field right now,
today. To me that's worse than an ECC failure. I'll go out on a limb and
say that "it doesn't work" is a worse problem than "it's insecure".

Java 7 and 8 clients can negotiate ECDHE instead of DHE, so what we're
seeing here is legacy cruft preventing the use of an otherwise semi-modern
configuration (for relative values of modern). If we simply shut the cruft
off, everything is great, and the handshake succeeds using a key exchange
facilitated by modern algorithms. I feel like I'm dealing with legacy knobs
that nobody in their right mind would turn, but simply by existing are
breaking the entire TLS communication channel from being established.

Java 6 can't negotiate DHE with a "secure" key size. The best it can do is
1024-bit. Both Java 6 and 7 are already EOL so there's little chance of
IETF drafts affecting them unless there's a server-side workaround that
isn't "shut off DHE".

Has someone actually implemented what's described in this draft and shown
it allows legacy Java clients to negotiate a secure DHE handshake? And even
if that's the case, why care about DHE instead of moving clients to ECDHE?

Who is this draft actually helping?

> 1) Deprecate/prohibit all "DH(E)_*" cipher suites

I'm a bit unclear on this, but I think that's actually happening as part of
TLS 1.3?

-- 
Tony Arcieri

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 3 Jun 2015 01:22:57 -0700

On Wed, Jun 3, 2015 at 1:07 AM, Peter Gutmann <[email-masked]>
wrote:

>
> *You've got that exactly reversed, it's not "DHE is breaking Java
> handshakes", it's "(Sun/Oracle's) Java is breaking DHE handshakes".*
>

Here in the real world things are written in Java and we have to deal with
that. Idealistically I'd wave a magic wand and all of the legacy cruft
would go away. Unfortunately I don't have that magic wand. I have to keep
the real-world systems talking to each other.

I want real-world solutions to real-world problems, not idealistic zealotry.

-- 
Tony Arcieri

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 3 Jun 2015 01:27:59 -0700

> I want real-world solutions to real-world problems, not idealistic

Worse, I didn't bring up Java. Java was specifically cited in argument of
this draft:

On Tue, Jun 2, 2015 at 5:54 AM, Hubert Kario <[email-masked]> wrote:

> as it was pointed out many times
>

^^^ perhaps this was the line that set me off, but this is painfully
antagonistic to me especially given what I've been dealing with recently.
Saying things like this is tantamount to a personal attack and if you have
a technical argument to make this is possibly the worst way you can prefix
it. Dear Hubert, don't frame your argument this way, it just makes me
dislike you.

adding support for ECC is complex (both because of compexity of ECC and
> because it's

Many JCE providers already support ECC including BouncyCastle and the
default JCE providers in Java 7 and 8 so this statement is just wrong.
Modern Java implementations just won't negotiate DHE unless the server
can't speak ECDHE.

> side in fear of breaking, for example, Java based clients

Please show me an HTTPS server I can point my DHE-enabled Java 6 and 7
clients at and have them successfully negotiate a TLS session. I dare you.

-- 
Tony Arcieri

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 3 Jun 2015 08:43:31 +0000

>I want real-world solutions to real-world problems, not idealistic zealotry.

You seem to want everyone to change their behaviour in order to accommodate
the fact that you've chosen to use a broken, buggy implementation, one that
has a well-known problem that's been documented for many, many years.  You'll
have to excuse us for not being terribly sympathetic.

(Heck, just switch to something other than Sun/Oracle's broken implementation
if it's that big a deal, try Bouncy Castle for example.  The point is, this is
your problem, not the IETF's.  If you want to complain to someone, take it up
with Sun/Oracle, the party responsible for the problem).

Peter.

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 3 Jun 2015 01:48:56 -0700

On Wed, Jun 3, 2015 at 1:43 AM, Peter Gutmann <[email-masked]>
wrote:

> the fact that you've chosen to use a broken, buggy implementation
>

These aren't clients under my control. I am talking about an entire
language ecosystem here, not just my little corner of the world. But even
if they were my clients, they wouldn't negotiate DHE anyway, because most
configurations would prefer ECDHE.

The "accommodation" you're defending is using finite-field Diffie-Hellman.
Most clients support ECDH(E) and don't need to support finite-field
Diffie-Hellman.

Finite field Diffie-Hellman is a slow, outmoded legacy key exchange
algorithm that in my opinion should completely be abandoned.

I didn't even bring up Java, but it was cited as a reason for FFDHE to
exist. However Java 7 and 8 clients would prefer ECDHE anyway. As they
should, it's faster and uses smaller keys.

This is a case of some legacy gunk left over from the early days of TLS
breaking key exchange for clients that support better algorithms.

We can either double down on the gunk, or shut it off.

*In practice* I have been telling people to shut it off and so far it's
been a successful solution to the problem.

Why should we keep this legacy gunk around? Who is it helping?

-- 
Tony Arcieri

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 03 Jun 2015 12:05:51 +0200

On Wed, 2015-06-03 at 01:48 -0700, Tony Arcieri wrote:
> *In practice* I have been telling people to shut it off and so far 
> it's been a successful solution to the problem.

I agree that DHE is old and slow comparing to ECDHE and typically you
wouldn't want it. However, it is one question to disable the
ciphersuites you don't want, and another to remove DHE as a negotiation
option for TLS. Removing the negotiation option means there there will
be no backup at all in case of a flaw in the existing ECDHE
ciphersuites.

If you plan to serve buggy clients with broken DHE support, then the
simplest approach is not to offer DHE to them. If you are in control of
these broken clients, then disable DHE support in them. The draft is
only slightly related to the issues you present on this thread.

regards,
Nikos

---

From: Hubert Kario <[email-masked]>
Date: Wed, 03 Jun 2015 12:28:32 +0200

On Tuesday 02 June 2015 23:35:46 Tony Arcieri wrote:
> aborting *before* they send the ClientHello.

sorry, that would be Spooky Action at a Distance...

> Please let me know if you're

as it was pointed out - if the client doesn't see a ff-dhe extension it should 
either default to non-dhe ciphersuite or a legacy key size (2048 bit or a 
dynamically generated 1024 bit one if compatibility with very old Java is 
required)

either of those solutions will make it possible to handle Java clients 
smoothly

Java clients get broken *because* we don't have this extension in widespread 
use

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 03 Jun 2015 08:47:46 -0700

Tony Arcieri wrote:
> On Wed, Jun 3, 2015 at 1:07 AM, Peter Gutmann wrote:
> 
>     *You've got that exactly reversed, it's not "DHE is breaking
>     Java handshakes", it's "(Sun/Oracle's) Java is breaking DHE
>     handshakes".*
> 
> Here in the real world things are written in Java and we have to deal 
> with that. Idealistically I'd wave a magic wand and all of the legacy 
> cruft would go away. Unfortunately I don't have that magic wand. I have 
> to keep the real-world systems talking to each other.
> 

I recently added version-specific DH parameter sizes to my server code.
When a client supports TLS 1.2, 2048-bit (or larger) parameters are used,
otherwise 1024-bit parameters are sent.  Legacy Java clients won't be
negotiating version 1.2 so they are still able to connect.

Unfortunately this feature fairs poorly when graded by SSL Labs because
it is currently unaware of version-specific DH parameters, though I hear
they are working on it.

Mike

---

From: Peter Bowen <[email-masked]>
Date: Wed, 3 Jun 2015 09:44:08 -0700

On Wed, Jun 3, 2015 at 1:48 AM, Tony Arcieri <[email-masked]> wrote:
> These aren't clients under my control. I am talking about an entire language
> ecosystem here, not just my little corner of the world. But even if they
> were my clients, they wouldn't negotiate DHE anyway, because most

There are three classes of clients today:
1) Clients that support ECDH key exchange (with at least the NIST
P-256 and NIST P-384 curves)
2) Clients that do not support ECDH but support FFDH with larger modp sizes
3) Clients that do not support ECDH but support FFDH only with smaller
modp sizes (e.g. max size is only 1024 bits or 2048 bits)

This draft supposes that there will continue to be clients that fall
into the second class for the foreseeable future and given them a way
to declare that they are not in the third class.  While we would all
like to see every client in the first class, I don't think that is a
real option for a few more years.  Until then, we should allow clients
to indicate that they will accept reasonable modp sizes.  That was a
server can choose to allow them to use FFDH for key exchange but not
offer FFDH for other clients.

Thanks,
Peter

---

From: Dave Garrett <[email-masked]>
Date: Wed, 3 Jun 2015 13:23:36 -0400

On Wednesday, June 03, 2015 04:20:15 am Tony Arcieri wrote:
> I'm a bit unclear on this, but I think that's actually happening as part of TLS 1.3?

No, that's what you're proposing with a diediedie. (seems to have been a miscommunication here)

DH_* (non-ephemeral) are being deprecated in TLS 1.3. DHE_* are still in TLS 1.3. You're argument is that non-ECC DH(E) is harmful because Java is crap and chokes on it. (yeah, Java should be fixed, but it is crap and out there and breaking, and getting rid of DH(E) would fix that)

> 2) Create a new set of "FFDHE_*" cipher suites to replace them that only allow strong groups (3072+)

My suggestion is to do exactly what you propose, publish a DH(E) diediedie, but in the same RFC standardize a new set of DHE cipher suites with strong requirements using a new prefix (e.g. FFDHE) and new codepoint assignments. Servers supporting these new suites will never negotiate them with old clients that don't support them, but newer clients that add support will be able to negotiate DHE using the new cipher suites.

It's a cake-and-eat-it-too suggestion. Kill old DH(E) and replace it with a limited set of new suites that are only usable with strong groups and only supported by new clients.

Dave

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 03 Jun 2015 13:48:39 -0400

On Wed 2015-06-03 13:23:36 -0400, Dave Garrett wrote:
> DH_* (non-ephemeral) are being deprecated in TLS 1.3. DHE_* are still
> in TLS 1.3. You're argument is that non-ECC DH(E) is harmful because
> Java is crap and chokes on it. (yeah, Java should be fixed, but it is
> crap and out there and breaking, and getting rid of DH(E) would fix
> that)
>
> What I said was:
> My suggestion is to do exactly what you propose, publish a DH(E)
> diediedie, but in the same RFC standardize a new set of DHE cipher
> suites with strong requirements using a new prefix (e.g. FFDHE) and
> new codepoint assignments. Servers supporting these new suites will
> never negotiate them with old clients that don't support them, but
> newer clients that add support will be able to negotiate DHE using the
> new cipher suites.
>
> It's a cake-and-eat-it-too suggestion. Kill old DH(E) and replace it
> with a limited set of new suites that are only usable with strong
> groups and only supported by new clients.

Alternately, we can get the same functionality with the
negotiated-ff-dhe draft:

 * servers compatible with the draft can choose to never negotiate ffdhe
   with clients that don't advertise support.

 * newer client will be able to negotiate ffdhe with these servers by
   advertising support.

The main difference depends on what newer clients want old servers to do:

   If clients are willing for old servers to go ahead and negotiate
   FFDHE ciphersuites even if their parameters might be dubious, then in
   your proposal they need to offer both sets of ciphersuites (possibly
   increasing the list of ciphersuites beyond 64, which may tickle other
   bugs [0])   

   If clients want old servers to never negotiate an FFDHE ciphersuite
   unless they're offering good parameters, then under your proposal
   they simply offer the new ciphersuites.  Under the current
   negotiated-ff-dhe draft, a client receiving bad parameters from the
   server has to abort a connection (and can subsequently re-try without
   listing any FFDHE ciphersuites if it wants).

For TLS 1.3, i'm expecting that any FFDHE ciphersuites will have a
radically different handshake, so very little of this is relevant (plus,
it will be TLS 1.3, so we can treat the existing ciphersuites
differently based on the version of the protocol in use).  So the
negotiated-ff-dhe draft aimed for the simplest, most minimal change for
1.2 and earlier.

Regards,

          --dkg

[0] e.g. see Message-ID: 20131107213744.GQ18713@localhost on this
    mailing list, "Windows 2003 TLS 64 ciphersuite limit" from Nico
    Williams, 2013-11-07

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 3 Jun 2015 20:57:13 +0300

> negotiated-ff-dhe draft aimed for the simplest, most minimal change for

On protocol level, in TLS 1.3-latest, the only difference between DHE
and ECDHE appears to be that DHE has 2-byte length filed, while ECDHE
has 1-byte length field (and both then are packed alone into variable-
length field with redundant 2-byte length field...).

-Ilari

---

From: Dave Garrett <[email-masked]>
Date: Wed, 3 Jun 2015 16:13:13 -0400

>    listing any FFDHE ciphersuites if it wants).

Yes, exactly.

> negotiated-ff-dhe draft aimed for the simplest, most minimal change for

The topic brought up by Tony Arcieri was the apparent plague of old Java clients using TLS currently. A replacement set of cipher suites would transparently fix this in a simpler way. It adds more suites, yes, but it would ensure that this is only ever even _attempted_ to be negotiated between clients and servers that both support them properly.

A replacement set of FFDHE cipher suites would also be useful to more clearly segregate the clients and servers that support strong FFDHE from those that support weak parameters. A server supported suites scan would very clearly show the capabilities without having to check the extension for more detail. Even if this could all be technically implemented without new suite names/codepoints, doing so could be safer to manage and a bit more mistake-resistant.

Dave

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 3 Jun 2015 13:50:59 -0700

On Wednesday, June 3, 2015, Dave Garrett <[email-masked]> wrote:

> The topic brought up by Tony Arcieri was the apparent plague of old Java
> clients using TLS currently. A replacement set of cipher suites would
> transparently fix this in a simpler way. It adds more suites, yes, but it
> would ensure that this is only ever even _attempted_ to be negotiated
> between clients and servers that both support them properly.

That's "half the battle", IMO, and I think the other half of my argument
was lost in a swarm of "LOL Java, there's your problem" responses. I also
called out the "what about a catastrophic ECC failure?" in advance and yet
that is somehow the main "pedantic" response I've been receiving to my
complaints.

I get it. I get it so much I predicted people would say it in my very first
post to this thread. Then they confirmed my hypothesis. But if we're
switching to ECC for certificates too, what hypothetical attack breaks ECDH
but not ECDSA/EdDSA/etc, and is it really worth convoluting TLS with extra
baggage in preparation of a hypothetical attack? Should everyone continue
to obtain RSA certs i. the event of an ECCpocalypse?  I'm pretty firmly
convinced people aren't really fully thinking through. The pat-on-the-head
"you don't understand we need this if ECC breaks" responses are myopic,
insulting, and an indicator that people aren't actually
reading/comprehending my arguments here (the same goes for "that's just a
Java problem" reaponses)

The main thing I'ge observed as an SSL/TLS practicioner is extra bells and
whistles that aren't commonly used leading to practial attacks, and people
making haphazard changes to defend against these attacks breaking clients
in the process. I care a lot more about the attacks and breakages happening
in the real world *right now* than extremely speculative future attacks for
which we're pre-emptively adding additional baggage/attack surface.

That said, I think everyone is convincing me FFDHE *might* be a good idea.
Particularly persuasive is Ilari's argument that with some tiny changes,
ECDHE and FFDHE can be unified.

-- 
Tony Arcieri

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 03 Jun 2015 17:02:10 -0400

> ECDHE and FFDHE can be unified.

I think this is the biggest reason as well.  Dropping FFDHE with the
idea that we would fall back to RSA for key exchange would mean breaking
with our goal of moving to all PFS handshakes for TLS 1.3 (modulo PSK,
resumption, etc).

Keeping FFDHE allows us an ECC fallback (should we need it) while
keeping an otherwise unified framework for the newer version of the
protocol.  It also means that existing clients and servers that do FFDHE
properly (not older java, as you note) can continue to work without
requiring cutover immediately.

        --dkg

---

From: Jeffrey Walton <[email-masked]>
Date: Wed, 3 Jun 2015 17:14:52 -0400

On Wed, Jun 3, 2015 at 4:50 PM, Tony Arcieri <[email-masked]> wrote:
> That's "half the battle", IMO, and I think the other half of my argument was
> lost in a swarm of "LOL Java, there's your problem" responses. I also called
> out the "what about a catastrophic ECC failure?" in advance and yet that is
> somehow the main "pedantic" response I've been receiving to my complaints.
>

One thing to keep in mind with the Java clients...

   SSLSocketFactory.getInstance("TLS");

will return a socket with SSLv3 and TLS 1.0 enabled. You will also get
the cipher suite zoo enabled. TLS 1.1 and 1.2 were even disabled for
Java 7 (Java 8 finally enabled them).

You have to jump through hoops to get something sane, like "TLS 1.0
and above with reasonable cipher suites". See, for example,
http://stackoverflow.com/a/23365536/608639.

So its not clear you would get desired behavior regardless of what
happens. Old clients won't get the updates, and old and new code often
won't utilize seek out desired socket behavior.

Jeff

---

From: Dave Garrett <[email-masked]>
Date: Wed, 3 Jun 2015 17:36:30 -0400

> ECDHE and FFDHE can be unified.

Actually, doing that completely is probably better than adding new suites. Just do "DH(E)_*" diediedie and allow new implementations that negotiate "ECDHE_*" to pick either a strong curve to do ECDHE or a strong group to do FFDHE, without needing to specify it in the suite.

Back in the discussion about ways to improve negotiation of capabilities to deal with the suite combinatorial explosion, the general consensus was that the simplest a la cart route would be to only negotiate symmetric ciphers via the suites and pick the rest via extensions, ignoring the parts in the suite. The usage of FFDHE or ECDHE would be based on what gets negotiated via the “supported_groups” extension. This could be the general way forward for TLS 1.3+ and for older TLS clients that want to deprecate "DH(E)_*" suites as well.

With this route, all endpoints that negotiate the use of the “supported_groups” extension would:
1) Consider all "(EC)DHE_*" suites to be equivalent; any *DHE* suite would use the same negotiation algorithm. (ephemeral only might be simplest; just ditch non-FS)
2) Usage of FFDHE or ECDHE would be chosen based on the negotiated named group/curve based on client priority.
3) Endpoints that no longer wish to ever negotiate any weak DHE would stop offering all "DHE_*" suites, which would now be considered deprecated.
4) The "ECDHE" prefix on suites would now essentially mean "ECC capable", rather than "only ECC".

Dave

---

From: Dave Garrett <[email-masked]>
Date: Wed, 3 Jun 2015 17:52:10 -0400

On Wednesday, June 03, 2015 05:36:30 pm Dave Garrett wrote:
> pick either a strong curve to do ECDHE or a strong group to do FFDHE

On the topic of "strong":

https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-10#appendix-A.1

estimated symmetric-equivalent strengths:
ffdhe2048:  103 bits
ffdhe3072:  125 bits
ffdhe4096:  150 bits
ffdhe6144:  175 bits
ffdhe8192:  192 bits

If we only wish to support strong groups, then we should consider dropping ffdhe2048 and require ffdhe3072 or higher. (likewise, prohibit all curves under a ~128 bit security level)

Also, a ~256 bit security level FFDHE group should probably be in the list, even if its performance is crap.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 3 Jun 2015 15:03:54 -0700

Please see:
http://www.ietf.org/mail-archive/web/tls/current/msg14438.html

On Wed, Jun 3, 2015 at 2:52 PM, Dave Garrett <[email-masked]> wrote:

> If we only wish to support strong groups, then we should consider dropping
> ffdhe2048 and require ffdhe3072 or higher. (likewise, prohibit all curves
> under a ~128 bit security level)
>

---

From: Tony Arcieri <[email-masked]>
Date: Thu, 4 Jun 2015 18:02:33 -0700

As I expected, one of the major issues seems to be having a backup in the
event of a catastrophic failure of ECC:

On Wed, Jun 3, 2015 at 1:05 AM, Dave Garrett <[email-masked]> wrote:

> People want a backup to deal with mistrust of ECC curves

On Wed, Jun 3, 2015 at 3:05 AM, Nikos Mavrogiannopoulos <[email-masked]>
 wrote:

> Removing the negotiation option means there there will

When I did a quick straw poll of the CFRG about this, the seemingly
unanimous preference was if we do want to solve the general problem of an
"ECC backup", we should be focusing on post-quantum algorithms, not shoring
up FFDHE.

I get the "RHEL5 problem" but I really don't care (sorry RedHat). It's
basically the opposite of the kind of legacy support I was asking for,
where we solve problems by *shutting off* legacy ciphers. Instead, to solve
the "RHEL5 problem" we have to *further complicate TLS*.

It seems people are colluding support for ancient clients with the need for
a backup in the event of an ECC disaster.

I think the matter of what to do about a backup option in the event of an
ECCpocalypse is a question for the CFRG, not the TLS mailing list.

--
Tony Arcieri

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 05 Jun 2015 10:44:47 +0200

On Thu, 2015-06-04 at 18:02 -0700, Tony Arcieri wrote:
> As I expected, one of the major issues seems to be having a backup in 
> the event of a catastrophic failure of ECC:
> > I expect the response is going to be "What if there's some 
> > catastrophic failure of ECC?"
> > 
> On Wed, Jun 3, 2015 at 3:05 AM, Nikos Mavrogiannopoulos <
> [email-masked]> wrote:
> unanimous preference was if we do want to solve the general problem 
> of an "ECC backup", we should be focusing on post-quantum algorithms, 
> not shoring up FFDHE.

I agree, but I don't see any proposals so far. Once we have such an
algorithm as backup we can drop FFDHE.

regards,
Nikos

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 5 Jun 2015 15:46:41 +0300

> algorithm as backup we can drop FFDHE.

Unfortunately, PQ algorithms (and there do seem to be PQ key agreement
algorithms that look sufficiently like Diffie-Hellman) are much less
understood than DH or ECDH.

Some relevant questions:
- How much assurance there is to security of such scheme in general?
- Approximately how fast the scheme runs (at least that it isn't
  hopelessly slow)?
- How does exchange key size scale as function of estimated security
  level (especially as TLS is currently limited to 64kB keys, and PQ
  schemes tend to have very large keys)?
- What mesages does the scheme need (especially, is it one from each
  in either order DH/ECDH has)?
- Can the scheme use fixed sets of public paramters (especially as
  TLS 1.3 key exchange has that limit)?
- How to perform trustworthy generation of the public parameters
  (some schemes have serious problems there)?
- What regions of public parameters to avoid because of security
  issues?

I don't know if this is even CFRG material at this point, let alone
material for TLS WG.

-Ilari

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 5 Jun 2015 13:48:57 -0700

On Fri, Jun 5, 2015 at 5:46 AM, Ilari Liusvaara <[email-masked]

> I don't know if this is even CFRG material at this point, let alone

I don't know if the CFRG is ready to tackle this problem at this point, but
I think the TLS WG is definitely the wrong place to tackle it.

-- 
Tony Arcieri