On Tue, Feb 03, 2026 at 05:36:33AM -0800, Mohamed Boucadair via Datatracker
wrote:
> # I wonder whether we need to remind the implications on the message size
> (e.g., a pointer to Section 4 of draft-ietf-tls-hybrid-design).
>
> As a side note, how current servers/middleboxes handle ClientHello that don’t
> fit in a single packet that might be observed if these groups are used? Are
> there any operational issues to take into account here?
Such operational considerations are hopefully a point-in-time
concern that may eventually become insignificant, but FWIW,
presently there are indeed some TLS servers behind middle-boxes
that don't tolerate larger multi-segment ClientHello.
For example, the now default OpenSSL pair of client keyshares
"X25519MLKEM768" and "X25519" does run into some friction,
and, for example, Postfix users are now advised:
https://www.postfix.org/postconf.5.html#tls_eecdh_auto_curves
... That said, when compiled against OpenSSL 3.5 or later, the
Postfix default setting is a minor adjustment of the OpenSSL
compiled-in default setting, it just delays generation of the hybrid
post-quantum X25519MLKEM768 key-share until it is explicitly
requested by the server. This avoids interoperability issues with
some SMTP servers that are unable to handle the resulting large TLS
Client Hello.
The underlying setting changes X25519MLKEM869 to still be supported and
preferred, but no longer included as a default keyshare, instead it will
only be sent after HRR.
https://github.com/vdukhovni/postfix/blob/11d1e54392f7411e7bc7990115fb5a62aff204f6/postfix/src/global/mail_params.h#L3463
If this sort of point-in-time operational advise is in scope for the
RFC, then a recommendation could be made to consider trading off latency
against interoperability. Then again this sort of advice might best be
left to the documentation of individual application packages that may be
more attuned to the state of their particular ecosystems at the time of
a given software release.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
