On Thu, May 29, 2025 at 12:22:10PM +0300, Viktor Ustiuhov via Exim-users wrote:
> > Actually, it is not surprising at all, the issue basically boils down to
> > whether the Client TLS fits in a single TCP segment or not. If it does
> > the handshake completes, otherwise not TCP ACKs are received and the
> > handshake times out. This is a middlebox issue. The server only
> > supports TLS 1.2 and no PQ key exchange.
>
> Is it appropriate to use a large default list of TLS groups like:
>
> mlkem1024:mlkem768:mlkem512:X25519MLKEM768:SecP256r1MLKEM768:X25519:prime256v1:X448:secp521r1:secp384r1
The effect of such a setting is to send *only* the first group listed as
the initial keyshare. This will almost always elicit an HRR from a
server unless "mlkem1024" is one of its most preferred set of kex key
types.
To send more than one initial keyshare, see the docs, and prefix the
groups that should be in the initial keyshare list with "*".
You'll probably find that "mlkem1024" is rarely worth sending, few if
any servers will support it.
> Or should such a list be minimized to avoid unnecessarily large
> ClientHello messages?
It only costs 2 bytes per element to send the list of supported
algorithms, it is the smaller subset (or else just the first element) if
prefixed with "*" that determine the size of the client hello.
> In this case, I'm no longer referring to problematic domains like
> boeing.com.
OpenSSL has a fairly sensible default list, that was chosen with care,
my advice is to just use the default.
--
Viktor.
--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscr...@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
