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 <ietf-d...@dukhovni.org>
Date: Sat, 31 Jul 2021 at 19:12
Subject: Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange
Methods in TLS
To: <tls@ietf.org>
On Sat, Jul 31, 2021 at 12:57:39PM +0000, Peter Gutmann wrote:
> Viktor Dukhovni <ietf-d...@dukhovni.org> 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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
