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 <
[email protected]> 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
> >
>
>

Reply via email to