Re: [quicwg/base-drafts] Editorial suggestions from Benjamin Kaduk's IESG review (qpack) (#4789)

[kaduk <[e-mail]>]

@kaduk commented on this pull request.



> @@ -1203,9 +1204,9 @@ the dynamic table state. If a guess is compressed into a shorter length, the
 attacker can observe the encoded length and infer that the guess was correct.
 
 This is possible even over the Transport Layer Security Protocol (TLS, see
-{{?TLS=RFC8446}}), because while TLS provides confidentiality protection for
-content, it only provides a limited amount of protection for the length of that
-content.
+{{?TLS=RFC8446}}) and QUIC Transport Protocol (see {{QUIC-TRANSPORT}}), because
+while TLS and QUIC provide confidentiality protection for content, they only
+provides a limited amount of protection for the length of that content.

Perhaps we should just not mention TLS at all?

> @@ -1235,12 +1236,12 @@ recovered successfully. However, values with low entropy remain vulnerable.
 Attacks of this nature are possible any time that two mutually distrustful
 entities control requests or responses that are placed onto a single HTTP/3
 connection. If the shared QPACK compressor permits one entity to add entries to
-the dynamic table, and the other to access those entries to encode chosen field

If you can "access" those entries, you're done already :)

> @@ -1277,6 +1279,11 @@ different values.  This penalty could cause a large number of attempts to guess
 a field value to result in the field not being compared to the dynamic table
 entries in future messages, effectively preventing further guesses.
 
+This response might be made inversely proportional to the length of the
+field value. Disabling access to the dynamic table for a given field name might
+occur for shorter values more quickly or with higher probability than for longer
+values.
+

This is just  moving the related paragraph up so the note appears at the end.

> @@ -1339,7 +1341,7 @@ An attacker can try to cause an endpoint to exhaust its memory. QPACK is
 designed to limit both the peak and stable amounts of memory allocated by an
 endpoint.
 
-The amount of memory used by the encoder is limited by the protocol using
+The amount of memory used by the decoder is limited by the protocol using

In some sense this is true as it is, but that's not a terribly interesting statement to make -- the encoder can limit its memory usage unilaterally, and could be sloppily implemented and exceed the protocol-conveyed limit.

> @@ -1717,7 +1719,7 @@ Stream: Decoder
                                3   0  custom-key  custom-value
                               ^-- acknowledged --^
                                4   0  :authority  www.example.com
-                              Size=215
+                              Size=217

The table hasn't changed from the previous state, properly shown as 217 bytes.

> @@ -1738,7 +1740,7 @@ Stream: Encoder
                               ^-- acknowledged --^
                                4   0  :authority  www.example.com
                                5   0  custom-key  custom-value2
-                              Size=215
+                              Size=214

I attempted to count the difference between `:authoritywww.example.com` and `custom-keycustom-value2`.

> @@ -1787,8 +1789,8 @@ for line in field_lines:
 
 # encode the prefix
 if requiredInsertCount == 0:
-  encodeIndexReference(prefixBuffer, 0, 0, 8)
-  encodeIndexReference(prefixBuffer, 0, 0, 7)
+  encodeInteger(prefixBuffer, 0, 0, 8)
+  encodeInteger(prefixBuffer, 0, 0, 7)

encodeIndexReference() is shown earlier with a different signature.  I know pythonic things do have optional parameters, but this seems to match the encodeInteger() signature perfectly, so I assume it was just an incomplete edit.  Though, stylistically perhaps the second argument should be `0x00` rather than a literal `0`.

-- 
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/4789#pullrequestreview-572785617