Mailing List Archive

On Sun, Jan 01, 2023 at 05:48:50AM +0000, admin--- via Exim-dev wrote:

> It is impossible to set a custom tls_eccurve if Exim is compiled against
> OpenSSL >= 3.0.0 due to a parenthesis error: The value of SSL_CTX_set1_groups
> rather than the comparison against 0 is assigned to rv, which subsequently
> fails at "return !rv;"
>
> https://github.com/Exim/exim/pull/89

For the record, in case anyone is reading this here and not just on the
bug tracker, nobody should be setting an explicit custom EC curve. The
interoperable setting is to enable curve negotiation, either with the
default set of curves (requires no code), or an explicit list:

https://github.com/vdukhovni/postfix/blob/master/postfix/src/global/mail_params.h#L3345-L3376
https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_server.c#L670
https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_dh.c#L303-L372

Where the above is just setup machinery for calling SSL_CTX_set1_curves()
with the desired list of curve ids:

https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_dh.c#L365

The relevant OpenSSL documentation is at:

https://www.openssl.org/docs/man3.0/man3/SSL_CTX_set1_curves.html

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.

This also means, now that I think about it, that the quoted Postfix code
perhaps needs a tweak to not inadvertently disable the TLS 1.3 FFDHE
groups (unless that's a feature).

--
Viktor.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

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"?
--
Cheers,
Jeremy


--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

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.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##