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.
I was told countless number of times by TLS people that middleboxes
*are* a concern in real life.
I honestly don't know.
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.
ECH contains public keys, not?
And with a new format there must be some negotiation of whether
both the network-facing server and the ultimate-end server support it
HRR happens only with network-facing server, no?
At least this is my vague understanding, it could be plainly wrong,
I'm not very familiar with ECH.
Regards,
Valery.
-Ekr
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
