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

[Viktor Dukhovni <[e-mail]>]

On Sun, Aug 01, 2021 at 02:27:22PM +0300, Nimrod Aviram wrote:

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

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.

On Sun, Aug 01, 2021 at 11:42:22AM +0000, Peter Gutmann wrote:
> Viktor Dukhovni <[e-mail]> 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.

-- 
    Viktor.