The text was written that way to allow for the possibility of an AEAD with a tag shorter than its block size (or the size necessary to get enough entropy for header protection). We don't have one of those presently and we might not ever. After all, 128 bits isn't that much to pay for strong integrity. There are some applications where we continue to get requests for shorter tags, so that's not guaranteed.
Imagine that you have an 8 byte tag and a 16 byte sample (there is one of these modes in RFC 9605). If that were to be used in QUIC, you would need to pad the payload to ensure that you have enough space to sample. If your true packet number length was 1, then you would have to include a minimum of 11 bytes of data in packets. As it is, three bytes is the minimum payload size. On Thu, Mar 13, 2025, at 21:22, Damien Neil wrote: > The protected payload is the output of the AEAD, and contains 16 bytes > of tag (for all functions permitted in RFC 9001). I don't think > "protected payload" is specifically defined in RFC 9001, but figure 7 > (https://www.rfc-editor.org/rfc/rfc9001.html#fig-sample) clearly shows > that the "Protected Payload" is the remainder of the packet following > the packet number. > > The header protection sample is 16 bytes long, and starts 4 bytes after > the start of the packet number. It may include some or all of the AEAD > tag. > > The packet number is 1-4 bytes long. Therefore, the header protection > sample skips the first 0-3 bytes of the protected payload. If the > packet number is 1 byte long, then the protected payload must contain > at least 3 bytes in addition to the 16 bytes of tag (and the header > sample will consist of the 16 bytes of tag). > > A simple approach to ensure adequate data for header protection samples > is to pad all unencrypted payloads to at least 3 bytes. > > - Damien > > On Thu, Mar 13, 2025 at 12:53 PM Florentin Rochet > <florentin.roc...@unamur.be> wrote: >> 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 >> > >>
