Re: [quicwg/base-drafts] Pad rather than shift the header protection offset (#2030)

[janaiyengar <[e-mail]>]

janaiyengar commented on this pull request.



> @@ -905,27 +905,31 @@ of the ciphertext from the packet Payload field.
 The same number of bytes are always sampled, but an allowance needs to be made
 for the endpoint removing protection, which will not know the length of the
 Packet Number field.  In sampling the packet ciphertext, the Packet Number field
-is assumed to be 4 bytes long (its maximum possible encoded length), unless
-there is insufficient space in the packet for a complete sample.  The starting
-offset for the sample is set to 4 bytes after the start of the Packet Number
-field, then is reduced until there are enough bytes to sample.
+is assumed to be 4 bytes long (its maximum possible encoded length).
+
+An endpoint MUST discard packets that are not long enough to contain a complete
+sample.
+
+To ensure that sufficient data is available for sampling, 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.  For the
+AEAD functions defined in {{?TLS13}}, which have 16 byte expansion and 16 byte

```suggestion
AEAD functions defined in {{?TLS13}}, which have 16-byte expansions and 16-byte
```

> -is assumed to be 4 bytes long (its maximum possible encoded length), unless
-there is insufficient space in the packet for a complete sample.  The starting
-offset for the sample is set to 4 bytes after the start of the Packet Number
-field, then is reduced until there are enough bytes to sample.
+is assumed to be 4 bytes long (its maximum possible encoded length).
+
+An endpoint MUST discard packets that are not long enough to contain a complete
+sample.
+
+To ensure that sufficient data is available for sampling, 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.  For the
+AEAD functions defined in {{?TLS13}}, which have 16 byte expansion 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.

Compound adjective.
```suggestion
bytes of frames for a 2-byte packet number encoding.
```

>  
 An endpoint SHOULD NOT send a stateless reset that is significantly larger than
 the packet it receives.  Endpoints MUST discard packets that are too small to be
 valid QUIC packets.  With the set of AEAD functions defined in {{QUIC-TLS}},
-packets less than 19 bytes long are never valid.
+packets less than 21 bytes long are never valid.

```suggestion
packets that are smaller than 21 bytes are never valid.
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2030#pullrequestreview-177469014