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/
