Hi, Based on the discussion yesterday, I made the following PR, which I think addresses all the remaining issues.
https://github.com/tlswg/super-jumbo-record-limit/pull/10 The main change is a variable-length length field inspired by QUIC. Other choices are possible. Cheers, John The size of the length field is variable and depends on the size of the encrypted_record. It uses a format similar to the variable-length encoding for non-negative integer values used in QUIC and specified in Section 16 of [RFC9000]. The variable- length integer encoding reserves the two most significant bits of the first byte to encode the integer encoding length in bytes. The integer value is encoded on the remaining bits, in network byte order. This means that integers are encoded on 1, 2, 3, or 4 bytes and can encode 6-, 14-, 22-, or 30-bit values, respectively. Table 1 summarizes the encoding properties. Values do not need to be encoded on the minimum number of bytes necessary. struct { opaque length<1..4>; opaque encrypted_record[TLSLargeCiphertext.length]; } TLSLargeCiphertext; +======+========+=============+==============+ | 2MSB | Length | Usable Bits | Range | +======+========+=============+==============+ | 00 | 1 | 6 | 0–63 | +------+--------+-------------+--------------+ | 01 | 2 | 14 | 0–16383 | +------+--------+-------------+--------------+ | 10 | 3 | 22 | 0–4194303 | +------+--------+-------------+--------------+ | 11 | 4 | 30 | 0–1073741823 | +------+--------+-------------+--------------+ Table 1: Summary of Integer Encodings.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
