I remember being confused by the same part of the RFC, and to have two
interpretations:
Interpretation 1, protected payload does not include the tag:
pn_len + min_payload_len = 4 + sample_len
=> min_payload_len = 20 - pn_len (we never sample the tag)
Interpretation 2, protected payload includes the tag:
pn_len + min_payload_len + 16 = 4 + sample_len
=> min_payload_len = 20 - 16 - pn_len
Then the text:
>The cipher suites defined in [TLS13] -- other than
TLS_AES_128_CCM_8_SHA256, for which a header protection >scheme is not
defined in this document -- have 16-byte expansions and 16-byte header
protection samples. >This results in needing at least 3 bytes of frames
in the unprotected payload if the packet number is encoded >on a single
byte, or 2 bytes of frames for a 2-byte packet number encoding.
indicates that the second interpretation might be the right one. I think
quiche implements neither of these interpretations (it goes with a
min_payload_len = 4). So I am still confused.
Best,
Florentin
Le 13/03/25 à 19:52, Christian Huitema a écrit :
I have a question regarding minimal size of packets. If you read
https://datatracker.ietf.org/doc/html/rfc9001#section-5.4.2, it has
text explaining that "packets are padded so that the combined lengths
of the encoded packet number and protected payload is at least 4 bytes
longer than the sample required for header protection". I am under the
impression that the "protected payload" length includes the length of
the AEAD checksum, and that when the checksum length is more than 4
bytes no padding is ever necessary. Am I wrong?
-- Christian Huitema
