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

From: Nimrod Aviram <[email-masked]>
Date: Sun, 1 Aug 2021 14:27:22 +0300

Looks like we have consensus for the following:
- Clients may choose to not support FFDHE, a la Chrome. I don't see
consensus for full deprecation of FFDHE, please correct me if I'm wrong.
- Clients must not connect when the server uses a group of less than 2048
bits.
- Clients may connect when the server uses a well-known, safe prime group
of at least 2048 bits (well-known might mean "from RFC 7919 plus the
built-in Postfix group", or other reasonable definitions).
- Clients may connect when the server uses a custom safe prime group of at
least 2048 bits, if the client verifies that the prime is safe.

The only point where we don't have consensus seems to be:
- For clients who choose to support FFDHE, when the server uses a custom
group of at least 2048 bits, and the client isn't willing to check
safe-primality, what should the client do?
(This only applies when FFDHE is chosen in practice, rather than ECDHE.)
My personal opinion is that both options - either allowing or forbidding
the client to connect - would be reasonable here.
Perhaps it'd be best to leave this specific point to the next WG meeting?
We can still make progress on the document in the meanwhile.

I'll also ask around if we can get some metrics, in general and
specifically pertaining to that last point.

thanks again everyone,
Nimrod

---------- Forwarded message ---------
From: Viktor Dukhovni <[email-masked]>
Date: Sat, 31 Jul 2021 at 19:12
Subject: Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange
Methods in TLS
To: <[email-masked]>

On Sat, Jul 31, 2021 at 12:57:39PM +0000, Peter Gutmann wrote:
> 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?

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.

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

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 1 Aug 2021 11:42:22 +0000

Viktor Dukhovni <[email-masked]> writes:

>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?

That's better :-).  That was my thought too, every DH/DLP keygen I've seen
generates either Sophie Germain or FIPS 186 primes/parameters, so on the off
chance that your server feels like generating custom primes you'd need to go
out of your way to generate unsuitable ones, i.e. you'd probably need to write
custom code specifically for bad prime generation, and if you're going to do
that then all bets are off anyway.

Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 1 Aug 2021 15:11:03 -0400

> Looks like we have consensus for the following:

IIRC we're not looking for consensus on the substance of the draft at
this point, this just a WG adoption call.  So the issues below do not
need to be resolved at this time...  We just happen to be taking the
opportunity to discuss them...

> - Clients must not connect when the server uses a group of less than 2048 bits.

And so, with confirmation from Peter Gutmann below that any custom
groups we're likely to encounter are almost certainly safe (given a
sufficiently large prime), I see no need to do anything beyond:

    - Client should set a floor on the FFDHE group size that is appropriate
      for its application ecosystem.  Typically 2048, in ecosystems where
      smaller groups are sufficiently rare to non-existent.

    - A few specific, previously recommended, "standard" groups might now be
      explicitly refused.

    - Given that neither of the above can be negotiated in TLS 1.2, some
      clients and servers might choose to drop support for FFDHE either
      in TLS 1.2 or across the board.

I don't see a realistic scenario in which sufficiently large ad-hoc
server DH parameters are a problem.  Only some specific "standard"
groups (from outdated informational RFCs, ...) of suspect provenance
might reasonably be blacklisted.

-- 
    Viktor.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 2 Aug 2021 13:04:13 +0000

Viktor Dukhovni <[email-masked]> writes:

>with confirmation from Peter Gutmann below that any custom groups we're
>likely to encounter are almost certainly safe

Well, I haven't examined every crypto library on the planet, it's not to say
there isn't something somewhere that implements its keygen as:

for i = 0 to 256
  dhprime[ i ] = rand();

but of the ones I'm aware of, when you ask for DLP parameters you get
something appropriate like Sophie Germain primes or FIPS 186 or equivalent,
e.g. Lim-Lee parameter generation.

>I don't see a realistic scenario in which sufficiently large ad-hoc server DH
>parameters are a problem.

+1.  Also if mentioning specific published values it'd be good to go with 3526
rather than 7919 due to the non-use of 7919 in implementations (unless there
are implementations using the 7919 primes while not implementing 7919 itself).

Peter.

---

From: Carrick Bartle <[email-masked]>
Date: Mon, 2 Aug 2021 12:44:57 -0700

Is there benefit in stating that the server SHOULD choose a safe group, even if the client is unable to negotiate one?

Either way, I would support deprecating FFDHE completely.

> On Jul 30, 2021, at 12:46 PM, Viktor Dukhovni <[email-masked]> wrote:
> 
> On Fri, Jul 30, 2021 at 07:30:31PM +0000, Scott Fluhrer (sfluhrer) wrote:
> 
>>> 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.
> 
> 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.
> 
> 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: Ilari Liusvaara <[email-masked]>
Date: Fri, 6 Aug 2021 21:50:26 +0300

On Thu, Jul 29, 2021 at 02:50:20PM -0700, Joseph Salowey wrote:
> 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.

Adopt. And then fold the material from deprecate-ffdhe in.

Then I think nobody cares about KRB5 key exchange:

- There are no AES ciphers for it.
- It does not work with TLS 1.3 at all, and there are no plans to make
  it work.

-Ilari

---

From: Carrick Bartle <[email-masked]>
Date: Mon, 9 Aug 2021 11:16:00 -0700

I support adoption.

> On Jul 29, 2021, at 2:50 PM, Joseph Salowey <[email-masked]> wrote:
> 
> 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: Loganaden Velvindron <[email-masked]>
Date: Mon, 9 Aug 2021 22:23:35 +0400

I also support adoption.

On Mon, Aug 9, 2021 at 10:16 PM Carrick Bartle
<cbartle891=[email-masked]> wrote:
> This is a working group call for adoption of Deprecating Obsolete Key Exchange Methods in TLS  (draft-aviram-tls-deprecate-obsolete-kex-00).  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: David Schinazi <[email-masked]>
Date: Mon, 9 Aug 2021 15:01:54 -0700

I support adoption.

David

On Mon, Aug 9, 2021 at 11:24 AM Loganaden Velvindron <[email-masked]>
wrote:

> Exchange Methods in TLS  (draft-aviram-tls-deprecate-obsolete-kex-00).

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 26 Aug 2021 20:04:26 -0700

There is general consensus to adopt this draft as a working group item.
There is an open issue as to what content from the FFDH draft to merge into
this one.   While that does not prevent us from bringing the draft into the
working group we will give some time to see if we can come to consensus on
the content to be merged in on the other thread.

Cheers,

The TLS Chairs