Archive

Moving to a three-byte length wouldn't do anything: extension bodies
themselves have two-byte lengths, so any longer lengths within an extension
is just a waste.

(To that end, because every field in a ClientHello has a two-byte length,
the longest possible syntactically valid ClientHello at all is 2 + 32 +
32 + 1 + 32 + 2 + 2^16-2 + 1 + 2^8-1 + 2 + 2^16 - 1 bytes, which is doesn't
fit in two-byte length, but nearly does. And, in practice, implementations
may impose length limits on incoming messages beyond that to avoid DoS
risks.)

On Sat, Feb 20, 2021 at 3:19 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
> Hiya,
>
> The CH in TLS has a 3 octet length. The payload in ECH has a
> 2-octet length. Hopefully that'll never matter but it's an
> inconsistency I don't recall coming up before. (Apologies if
> I've forgotten, or if I've missed something in 8446 that
> forbids bigger CH's.)
>
> I'm fine with just leaving it as-is, or with noting in the
> text that you will suffer this problem (and many others;-) if
> you want to use a CH that's that long, or with moving to a 3
> octet length for the payload.
>
> Cheers,
> S.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

Re: [TLS] ech/esni - theoretically some inner CH's wouldn't fit...