On Mon, Jan 02, 2023 at 03:25:17PM +0000, Jeremy Harris via Exim-dev wrote:
> On 02/01/2023 04:16, Viktor Dukhovni via Exim-dev wrote:
> > Mind you, things are a bit complicated with TLS 1.3, where ECDHE groups
> > and FFDHE groups are unified and always negotiated, and setting the
> > grouplist to just ECDHE groups will disable FFDHE.
>
> Is there any particular advantage, or behaviour difference, in
> FFDHE vs. ECDHE?
>
> Is it mostly "EC keys are smaller, for equivalent protection"?
In TLS 1.3, the difference is largely performance. It isn't only that
are FFDHE keys are larger for the same security level, but rather that
the CPU cost of the key exchange rises much faster as a function of the
effective symmetric security bits than with ECDHE.
In TLS 1.0–1.2, the story is more complex, because the FFDHE group is
not negotiated, the server just picks whatever group it sees fit. This
choice could have a security benefit (resist precomputation attacks if
each server is configured with a locally generated strong set of DH
parameters), or it could be weak (1024-bit), or needlessly slow (8192
bit), or perhaps even some form of MITM downgrade attack (a small
subgroup attack that somehow works, though server signatures over the
key exchange parameters are expected to prevent this).
This is why there is an active thread on the TLS WG list about
deprecating FFDHE in TLS 1.2. (IMHO there is a better path forward,
to make ECDHE MTI, and preferred when mutually available, ... raise
the ceiling, not the floor, but I'm likely in the minority along
with the usual suspects like Peter Gutmann).
Anyway, in TLS 1.3, FFDHE groups are negotiated, just like the ECDHE/ECX
groups, so performance is the only consideration, but FFDHE is there as
a fallback in case we need to urgently drop support for the EC
algorithms, or some peer (client or server) does not support ECDHE/ECX
for some reason. [ ECX here means X25519 or X448. ]
For Postfix, I'll probably need to add a second configuration parameter
for the FFDHE groups, and when OpenSSL is 3.0 or later, ask OpenSSL
to enable the union of the two lists.
In Exim, the set of supported EC/ECX curves should not be a singleton.
Interoperability considerations strongly suggest that both clients and
servers should support a range of curves, at least one of which (say
P-256 and perhaps also X25519, making two) is MTI.
Similarly, for FFDHE, the set of supported groups (if any are supported)
should include at least ffdhe2048 and ffdhe3072. My personal take is
that 4096-bit RSA and FFDHE are too slow to be useful, if you want that
security level use EC. Enable 4096-bit RSA and FFDHE only if EC fails,
but FFDHE survives and 4096-bit RSA/FFDHE is all that's available.
--
Viktor.
