On Thu, Mar 19, 2026 at 8:21 PM Valery Smyslov <[email protected]>
wrote:
> Hi Eric,
>
>
>
> thank you for your comments. Please see inline.
>
>
>
> the right approach is to address this head-on, as follows:
>
> 1. Modify the ClientHello format to remove the limit.
> 2. Have a way for the client to learn it can use the new ClientHello
> format.
>
> The fix for (1) is straightforward: replace some if not all of the
> variable-length vectors with fixed limits with ones with
> variable-length limits as in MLS's `T<V>` syntax (see RFC 9420 S
> 2.1.2). Once you have done this, then you can just naturally carry
> arbitrarily large extensions. We can discuss whether this would be a
> global replacement (all vectors) or a targeted one
> ("large_extensions").
>
> Yes, the MLS-like encoding of the length is possible and thank
> you for bringing it.
> My concern here (perhaps wrong) is middleboxes.
> If they don't understand new format they can drop these messages.
> With a separate message (after the CH or SH) they (hopefully)
> will ignore anything outside the CH and SH.
>
I don't see any reason to think that that's true. In any case, those
middleboxes
are defective and we should not cater to them.
a bunch of round trips. It *might* be worth it for ECH, but I'd
> want to see some evidence that ECH was really going to exceed 64K.
>
> ECH is a concern.
>
Why? McEliece ciphertexts are small.
-Ekr
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
