Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)

From: Peter Gutmann <[email-masked]>
Date: Tue, 16 Aug 2016 10:44:47 +0000

I've been looking through this in a bit more detail and have found some pretty
problematic text in there...

   If a compatible TLS server receives a Supported Groups extension from
   a client that includes any FFDHE group (i.e., any codepoint between
   256 and 511, inclusive, even if unknown to the server), and if none
   of the client-proposed FFDHE groups are known and acceptable to the
   server, then the server MUST NOT select an FFDHE cipher suite.  In
   this case, the server SHOULD select an acceptable non-FFDHE cipher
   suite from the client's offered list.

As far as I can see what this text is saying is that if the client can't guess
in advance which PFS suite/group the server knows about, the server must
disable use of PFS.  In other words instead of saying "give me a PFS suite,
preferably with this group", it's saying "give me a PFS suite with exactly
this group and if you can't do that, don't do PFS".  This seems like a pretty
awful way to handle things.

This is reinforced by:

   A compatible TLS server that receives the Supported Groups extension
   with FFDHE codepoints in it and that selects an FFDHE cipher suite
   MUST select one of the client's offered groups.

In my mind this makes the FFDHE extension so toxic to use that I'd rather not
support it at all, because it disables PFS unless you're really lucky in
guessing what the server can do.  Either that or it'll be like certain parts
of TLS 1.2 where everyone knows that you need to ignore what the spec says in
order for things to work...

Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 16 Aug 2016 14:55:48 +0000

> awful way to handle things.

The client is expected to send a complete list of *all* the groups
it supports if it supports (any of) the new designated groups.
Which means that clients that support these groups will use only
these groups with servers that likewise suppose these groups, and
will not use FFDHE when the client group list and the server group
list don't overlap (which is seems unlikely).

> guessing what the server can do.

There's no guess, the client sends its full list of supported
groups, and the server picks the one it likes.

-- 
	Viktor.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 16 Aug 2016 15:34:36 -0500

> awful way to handle things.

Recall that the "perfect" part depends on both sides doing what they're
supposed to.  And if the server wants to behave badly and is doing a
not-named group, it can send something that is not prime, or has small
subgroups, etc. -- not all clients will check, so the client is
definitely not guaranteed forward secrecy.

-Ben

---

From: Watson Ladd <[email-masked]>
Date: Tue, 16 Aug 2016 13:36:49 -0700

On Tue, Aug 16, 2016 at 1:34 PM, Benjamin Kaduk <[email-masked]> wrote:
> subgroups, etc. -- not all clients will check, so the client is definitely
> not guaranteed forward secrecy.

A malicious server can also send the PMS to the Nation State
Adversary. Compromised endpoints offer no security.

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

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 17 Aug 2016 11:34:10 +0000

Viktor Dukhovni <[email-masked]> writes:

>The client is expected to send a complete list of *all* the groups it
>supports if it supports (any of) the new designated groups. Which means that
>clients that support these groups will use only these groups with servers
>that likewise suppose these groups, and will not use FFDHE when the client
>group list and the server group list don't overlap (which is seems unlikely).

But the text above says that if the server doesn't support what the client
asks for, you can't use PFS/DH/FFDHE/whatever you want to call it at all.  I
don't care whether the server does exactly ffdhe2048 or not, I'll take
ffdhe2048 if available, otherwise anything DHE as long as it's over about 1536
bits, and for a lot of clients my code is used in, under about 3K bits because
they don't have the CPU for more than that, and in addition don't need that
level of security.  However, what the above text says is that if the server
can't do exactly ffdhe2048 then it's not allowed to do any DHE at all and has
to use RSA.

>There's no guess, the client sends its full list of supported groups, and the
>server picks the one it likes.

... and if the client doesn't get it exactly right, the server has to fall
back to RSA rather than use another DHE suite of its choosing.

Peter.

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 17 Aug 2016 09:50:00 -0700

Peter, so your complaint is about the lack of support for explicitly
specified (non-"named") groups? That's completely intentional, see the
RFC's abstract. (It *shouldn't* be that much of a problem that the server
might be using a ill-chosen group, because if the server does dumb things
we can't save it anyway. However, given all the complexities of the TLS
handshake, there's actually more that can fall apart if the group is bad.)

Bodo

---

From: Geoffrey Keating <[email-masked]>
Date: 17 Aug 2016 14:47:35 -0700

> back to RSA rather than use another DHE suite of its choosing.

I believe that's the intention; the assumption is that the client
using this extension doesn't want DHE parameters that it doesn't have
configured, it only wants one of a pre-validated list of
groups/generators.  It especially doesn't want the server to say
"well, I know the client listed only groups 2048-bit and higher, but I
have this 512-bit group, let's use that".

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 19 Aug 2016 12:29:23 +0000

Bodo Moeller <[email-masked]> writes:

>specified (non-"named") groups?

It's the lack of support for DHE unless it's the exact parameters the server
wants.  At the moment if your implementation wants to use DHE (which pretty
much all of them do) you have two options:

1. Ignore RFC 7919 and perform DHE with several billion devices worldwide.

2. Implement RFC 7919 and, unless both client and server happen to choose an
   appropriate FFDHE parameter set that both sides can agree on, be forced to
   fall back to the old, unsafe RSA key exchange.

The problem is that 7919 doesn't say "I want to do DHE, if possible with these
parameters", it says "I will only accept DHE if you use these parameters,
otherwise you cannot use DHE but must drop back to RSA".  Talk about cutting
off your nose to spite your face, you'd have to have rocks in your head to
want to break your implementation like that.

Until now I hadn't had a major interest in 7919 (it's rather hard to identify
what problem it's actually solving), but thought I'd look at it for TLS-LTS
use.  However, if using it requires giving up DHE in a lot of cases there's no
way I'll be implementing it.

Peter.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 19 Aug 2016 15:56:58 +0300

>    fall back to the old, unsafe RSA key exchange.

AFAIK, that failure can only happen if at least one of:

- The server is buggy.
- All client-supported FFDHE groups are distrusted or not implemented
  on server (Yes, plural).
- All client-supported FFDHE groups are outside server key size range
  (in which case you probably wouldn't want to try to do DHE with that
  client anyway).

Because otherwise there is always a group choice that works. 

(I would say that 256+257+258 [2k, 3k and 4k] is reasonable set to
implement, 259 and 260 [6k and 8k] are too large).

-Ilari

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 19 Aug 2016 13:03:22 +0000

>AFAIK, that failure can only happen if at least one of:

[...]

New groups are introduced but the server or client only support the old ones.
So the server does ffdhe2048, the client does ffdhe2048', both are quite happy
to do DHE-2048 but as a result of complying with 7919 they're forced to use
RSA.

Peter.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 19 Aug 2016 16:20:46 +0300

> to do DHE-2048 but as a result of complying with 7919 they're forced to use

Oh, and if you think this is bad, wait until you get to TLS 1.3, where
you don't get fallback to RSA or some random DH group, you get almost
certain connection failure. :->

-Ilari

---

From: Watson Ladd <[email-masked]>
Date: Fri, 19 Aug 2016 06:52:00 -0700

> to do DHE-2048 but as a result of complying with 7919 they're forced to use

Let's assume we don't introduce more groups for no reason. Oh wait, we
totally did with ECC with this outcome. Let's not do that again.

---

From: Geoffrey Keating <[email-masked]>
Date: 19 Aug 2016 11:35:45 -0700

Peter Gutmann <[email-masked]> writes:

> The problem is that 7919 doesn't say "I want to do DHE, if possible
> with these parameters", it says "I will only accept DHE if you use
> these parameters, otherwise you cannot use DHE but must drop back to
> RSA".  Talk about cutting off your nose to spite your face, you'd
> have to have rocks in your head to want to break your implementation
> like that.

Actually, my problem with the RFC is the reverse.  If you have an
implementation which won't accept certain DH groups, and those are
extremely common in legacy software (1024-bit, for example), there's
no way to stop those legacy implementations ignoring the extension and
choosing DH, which you will then have to reject, doubling connection
establishment time.

So Apple's client still has DH off.

However I don't see a helpful solution to this; the obvious thing is
to have a new ciphersuite, but it's hard to see how that would be
worth the effort if it requires new implementations and ECDHE is
already standardised and already implemented in many places.

---

From: David Benjamin <[email-masked]>
Date: Fri, 19 Aug 2016 18:43:12 +0000

> already standardised and already implemented in many places.

TLS 1.3 will resolve this with the new cipher suite negotiation, but I
agree this makes the specification basically undeployable with TLS 1.2.
This issue also got brought up here:
https://www.ietf.org/mail-archive/web/tls/current/msg18697.html

Barring unforeseen problems, Chrome will also lose DH in the next release.
We certainly could not deploy this without the separate cipher suite
numbers. But I can't imagine Chrome deploying it with the separate cipher
suite numbers either for the same reason as Geoffrey. It does not seem
worth bothering when ECDHE is already widely deployed.

David

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 27 Aug 2016 13:27:15 +0000

David Benjamin <[email-masked]> writes:

>TLS 1.3 will resolve this with the new cipher suite negotiation, but I agree
>this makes the specification basically undeployable with TLS 1.2. This issue
>also got brought up here:

Hmm, good point.  So reading between the lines of the various comments on this
issue, the feeling seems to be "ignore this RFC".  That more or less answers
my question, I'll leave it out of TLS-LTS apart from mentioning it as another
source of DH groups.

>Barring unforeseen problems, Chrome will also lose DH in the next release.

Which will be yet another headache for people working with SCADA devices, who
are seeing themselves locked out more and more from being able to admin their
systems when browser vendors arbitrarily decide to deprecate long-established
mechanisms.  I know of operators who are running IE 6 in XP VMs because that's
the only thing that'll still talk to some devices they use (OK, old versions
of FF and Chrome will do it too if you can find them, but then they always
want to update themselves to less old versions that stop working again). 

Couldn't Chrome include an optional legacy mode that just works with existing
systems, perhaps triggered by access to a device at an RFC 1918 address?
There really is, in some cases, nothing available any more that will talk to
entire families of SCADA devices because browsers assume the only thing that
matters is the public WWW and won't accommodate anything that isn't.

(At some point someone's going to figure out they can make a lot of money by
taking Firefox 3.0, rebranding it, and selling it as an embedded device
management solution, because it'll talk to all the things that current
browsers won't any more).

Peter.

---

From: Ryan Hamilton <[email-masked]>
Date: Sat, 27 Aug 2016 07:28:31 -0700

On Sat, Aug 27, 2016 at 6:27 AM, Peter Gutmann <[email-masked]>
wrote:

> agree

​Alternatively, someone could write a "Legacy TLS" to "Current TLS" proxy,
which could run on the client's computer to sit in front of these legacy
devices. This would allow browsers to continue adding new security features
to protect users, while still allowing access to legacy systems.​

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 27 Aug 2016 17:38:20 +0300

> my question, I'll leave it out of TLS-LTS apart from mentioning it as another

The bad thing about allowing server to specify arbitrary group is that
the group can be such that the client does not like it. E.g.

- Too short modulus
- Bad modulus
- Used subgroup not big enough.

The first one is essentially what kills the DH in TLS 1.2.
 
> mechanisms. 

It is not "arbitrarily". Thinking back, every TLS-related deprecation I
am aware of is because at least one of:

- The mechanism is known to have serious security issues.
- The mechanism causes serious usability issues.
- Virtually nobody uses it (and any use is probably due to misconfig).

And with browsers, deprecating stuff takes way more time than it should
because of "compatiblity".

Most of this is because of bad design. Back in 2002 we would have had
all the technology necressary to design stuff that would still be
standing 14 years later in 2016, with no hint of breaking in near
future. Sure, it would be relatively slow, but that's no security
issue.

TLS is full of bad decisions (many inherited from SSL v3) that are
still haunting us, and it takes pretty much radical redesign (a.k.a.
TLS 1.3) to fix it.

> matters is the public WWW and won't accommodate anything that isn't.

Even supporting systems like that is serious security issue. Basically
if one even supports weak crypto, there usually are ways to enable it
when it should not be enabled, totally compromising security.

Whitness the multitude of attacks against TLS that exploit support
for weak crypto or bad protocol versions. Even if "disabled".

> browsers won't any more).

Well, I'm not aware of anything stopping anyone from doing that...

-Ilari

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 28 Aug 2016 11:48:52 +0000

Ryan Hamilton <[email-masked]> writes:

>Alternatively, someone could write a "Legacy TLS" to "Current TLS" proxy,
>to protect users, while still allowing access to legacy systems.?

Yep, that'd be the other way of doing the "embedded device management
solution".  Mind you I think these already exist, they're just called
antivirus proxies and security scanners [0].

Peter.

[0] Referring to the number of these that ignore cert checking, allow weak
    keys and ciphers, and so on.