Subject: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

From: Joseph Salowey <[email-masked]>
Date: Thu, 29 Jul 2021 14:50:20 -0700

This is a working group call for adoption of Deprecating Obsolete Key
Exchange Methods in TLS  (draft-aviram-tls-deprecate-obsolete-kex-00
<https://datatracker.ietf.org/doc/draft-aviram-tls-deprecate-obsolete-kex/>).
There was support for adopting this draft at the IETF 111 meeting.  Please
review the draft and post your comments to the list by Friday, August 13,
2021.

Thanks,

The TLS chairs

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 29 Jul 2021 22:07:56 +0000

>This is a working group call for adoption of Deprecating Obsolete Key Exchange Methods in TLS  (draft-aviram-tls-deprecate-obsolete-kex-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-aviram-tls-deprecate-obsolete-kex/__;!!GjvTz_vk!CUaGTbvSYQ3DqDrOKc8u-gxiKl8fNJqub7cH02BMcUQ1RgVfZ05cd5LLqbQG$>).  There was support for adopting this draft at the IETF 111 meeting.

I support adoption and will work to help make it better.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 30 Jul 2021 10:34:55 +1000

On Fri, Jul 30, 2021, at 07:50, Joseph Salowey wrote:
> <https://datatracker.ietf.org/doc/draft-aviram-tls-deprecate-obsolete-kex/>).  There was support for adopting this draft at the IETF 111 meeting.  Please review the draft and post your comments to the list by Friday, August 13, 2021.  

Yep, let's do it.  There were comments suggesting that this wasn't going to work for some deployments yet.  That's OK, that's how this works: we decide to deprecate, discuss and publish a document, then people get to work out how they change their deployments.  If we don't take that first step, then in many ways things don't get better.  Adopting this is that first step and a good idea.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 29 Jul 2021 20:44:59 -0400

On Fri, Jul 30, 2021 at 10:34:55AM +1000, Martin Thomson wrote:

> Yep, let's do it.  There were comments suggesting that this wasn't
> going to work for some deployments yet.  That's OK, that's how this
> works: we decide to deprecate, discuss and publish a document, then
> people get to work out how they change their deployments.  If we don't
> take that first step, then in many ways things don't get better.
> Adopting this is that first step and a good idea.

I support adoption of the draft and deprecation of RSA key exchange.

For FFDHE, I'd much rather see outright deprecation a la Chrome, than a
silent restriction by client (with no mechanism to negotiate otherwise0
to parameters that the server may not be prepared to support.

The only other alternative is to define brand new TLS 1.2 FFDHE cipher
code points that use negotiated groups from the group list.  But it is
far from clear that this is worth doing given that we now have ECDHE,
X25519 and X448.

There is far less risk of interoperability failure if the client or
drops support for FFDHE, rather than silently chooses to reject
previously working parameters.

-- 
    Viktor.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 30 Jul 2021 05:14:08 +0000

Viktor Dukhovni <[email-masked]> writes:

>The only other alternative is to define brand new TLS 1.2 FFDHE cipher code
>points that use negotiated groups from the group list.  But it is far from
>clear that this is worth doing given that we now have ECDHE, X25519 and X448.

There's still an awful lot of SCADA gear that does FFDHE, and that's never
going to change from that.  The current draft as it stands is fine, in fact it
seems kinda redundant since all it's saying is "don't do things that you
should never have been doing in the first place", but I assume someone needs
to explicitly say that.  No need to go beyond that.

Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 30 Jul 2021 14:56:50 -0400

> to explicitly say that.  No need to go beyond that.

Can you explain what you mean by "don't do things that you should never
have been doing in the first place"?

There are quite a few deployments that generate local strong (Sophie
Germain prime) DH parameters.  These would break if the draft sails
through as-is, and there's no mechanism for the client to inform the
legacy server that its would be choice of DH parameters is not
acceptable.

Was it wrong to generate server-side DH parameters?

-- 
    Viktor.

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Fri, 30 Jul 2021 19:30:31 +0000

> Was it wrong to generate server-side DH parameters?

The problem is that it is hard for the client to distinguish between a well designed server vs a server that isn't as well written, and selects the DH group in a naïve way.

For example, if the server just selects a random prime and a random generator value, well, that has a good probability of leaking quite a bit of information about the private exponents; leak enough, and the shared secret may be recoverable.  This is not obvious to someone new to the field; it is also very hard to detect by the client.

Now, as I mentioned in the WG meeting, it would be possible to detect if the server proposes a safe prime (it's not especially cheap, being several times as expensive as the rest of the DH operations, but it's possible), and that would prevent most of the problems that can happen (exception: if the server proposes an SNFS-friendly modulus, say, one with a very simple binary representation - that would reduce the security noticeably).  Of course, this works only if the legacy servers you are talking about actually do use safe primes...

-----Original Message-----
From: TLS <[email-masked]> On Behalf Of Viktor Dukhovni
Sent: Friday, July 30, 2021 2:57 PM
To: [email-masked]
Subject: Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

On Fri, Jul 30, 2021 at 05:14:08AM +0000, Peter Gutmann wrote:

> >The only other alternative is to define brand new TLS 1.2 FFDHE 
> >cipher code points that use negotiated groups from the group list.  
> >But it is far from clear that this is worth doing given that we now have ECDHE, X25519 and X448.
> 
> There's still an awful lot of SCADA gear that does FFDHE, and that's 
> never going to change from that.  The current draft as it stands is 
> fine, in fact it seems kinda redundant since all it's saying is "don't 
> do things that you should never have been doing in the first place", 
> but I assume someone needs to explicitly say that.  No need to go beyond that.

Can you explain what you mean by "don't do things that you should never have been doing in the first place"?

There are quite a few deployments that generate local strong (Sophie Germain prime) DH parameters.  These would break if the draft sails through as-is, and there's no mechanism for the client to inform the legacy server that its would be choice of DH parameters is not acceptable.

-- 
    Viktor.

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 30 Jul 2021 15:46:33 -0400

On Fri, Jul 30, 2021 at 07:30:31PM +0000, Scott Fluhrer (sfluhrer) wrote:

> The problem is that it is hard for the client to distinguish between a
> well designed server vs a server that isn't as well written, and
> selects the DH group in a naïve way.

I am well aware that verifying the safety of the server's choice is
computationally taxing.

> Now, as I mentioned in the WG meeting, it would be possible to detect
> if the server proposes a safe prime (it's not especially cheap, being
> several times as expensive as the rest of the DH operations, but it's
> possible), and that would prevent most of the problems that can happen

I don't think it is realistic for the client to go to that much trouble.
The server's choice of parameters is signed by the server's public key.
What is the threat model here?  Is the client trying to avoid servers
that shoot themselves in the foot by verifiably choosing bad parameters?

The server could also have a strong DH group, but a terrible RNG with a
well known RSA private key:

    http://dnssec-stats.ant.isi.edu/~viktor/mailcow.html

If the server is not one of these or similar, and attests to its choice
of DH parameters, and they happen to be less than ideal, so be it.
Server operators should be encouraged to choose strong parameters, but I
see little reason for clients to second-guess that choice.

If the DH parameter size is below a reasonable threshold (Logjam), a
client might balk, but otherwise I am not sure what practical problem
we're actually solving.

> Of course, this works only if the legacy servers you are talking about
> actually do use safe primes...

All the ones I know of use "openssl dhparam", which defaults to Sophie
Germain strong primes with generator 2.

I strongly doubt there's a non-negligible server population with weak
locally generated groups.  The only likely source of weak groups is
servers that used one the older now deemed weak groups published in
deprecated RFCs.

So it might suffice to refuse specific known weak "standard" groups,
which would have a much lower impact than requiring particular standard
groups with no mechanism to negotiate these.

-- 
    Viktor.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 31 Jul 2021 12:49:55 +0000

>been doing in the first place"?

Just what the draft says, don't use static-ephemeral DH, don't reuse DHE
secrets, etc.  It seems a bit like publishing an RFC telling people not to
stick forks in light sockets, but I guess enough people must have been
sticking forks in light sockets to make it necessary.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 31 Jul 2021 12:54:02 +0000

Scott Fluhrer (sfluhrer) <sfluhrer=[email-masked]> writes:

>The problem is that it is hard for the client to distinguish between a well
>designed server vs a server that isn't as well written, and selects the DH
>group in a naïve way.

What should the client do if it could detect this?  And how would it
distinguish between a server that selects bad DH parameters, a server that
uses time() to seed its RNG for prime generation, a server that has a buffer
overflow allowing RCE, and a server whose ACLs allow read/write access to any
file on the filesystem including its private key(s)?

>Now, as I mentioned in the WG meeting, it would be possible to detect if the
>server proposes a safe prime (it's not especially cheap, being several times
>as expensive as the rest of the DH operations, but it's possible),

Or you could use TLS-LTS, which sends { p, q, g } allowing the client to
verify certain properties about the primes being used at next to no cost.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 31 Jul 2021 12:57:39 +0000

Viktor Dukhovni <[email-masked]> writes:

>I strongly doubt there's a non-negligible server population with weak locally
>generated groups.

Would you care to rephrase that so we can make sure you're saying what we
think you're saying in order to disagree with it?

Peter :-).

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 31 Jul 2021 12:11:47 -0400

> think you're saying in order to disagree with it?

OK, who goes around bothering to actually generate custom DH parameters,
and with what tools, but then does not use a "strong" (Sophie Germain)
prime?

The only weakness I expect to encounter is a deprecated size of e.g.
512, 768 or 1024 bits.  Clients can easily detect that and enforce a
floor, but of course still don't get to negotiate a minimum.

Clients also don't get to negotiate the size of the server's RSA public
key, or as you mentioned various other ways for the server to not screw
up.

-- 
    Viktor.