Re: TLS group selection (incl. post-quantum hybrids) in remote_smtp

Viktor Dukhovni via Exim-users wrote on 29.05.2025 11:52:
> On Thu, May 29, 2025 at 11:39:54AM +0300, Viktor Ustiuhov via Exim-users wrote:
> 
>>> One approach that is likely to work-around PQ-impedance is to set the
>>> protocol version to TLSv1.2 (fixed or ceiling).  In that case, PQ
>>> keyshares aren't sent and STARTTLS works with "boeing.com" (still
>>> hangs with default TLS 1.3 connections under OpenSSL 3.5).
>>>
>>
>> By the way, I’ve found that it’s possible to connect to the MX hosts of
>> the boeing.com domain using mlkem512:
>>
>> openssl s_client -connect clt-mbsin-01.mbs.boeing.net:25 -servername
>> clt-mbsin-01.mbs.boeing.net -starttls smtp -groups mlkem512
>>
>> Apparently, the connection doesn’t hang in this case because the
>> ClientHello is smaller than when using X25519MLKEM768, mlkem768, or
>> mlkem1024.
>> However, it’s surprising that I don’t see the key_share extension in the
>> ServerHello.
> 
> 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

Or should such a list be minimized to avoid unnecessarily large
ClientHello messages?

In this case, I'm no longer referring to problematic domains like
boeing.com.


-- 
Best wishes Viktor Ustiuhov
mailto:[email protected]

-- 
## subscription configuration (requires account):
##   https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
##   [email protected]
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/