Draft: draft-ietf-quic-http

Commentary: Section 6.2.3 : These streams have no semantics , and can be sent when application - layer padding is desired . So although a bit unclear I assume the intention here is that one can grab the next available unidirectional stream , send the stream type with a reserved value . After that that endpoint may send arbitrary data at any time while the connection lasts and close it down . I think that could be slightly more explained . What is the cause of this issue is the " Application - layer padding " . So I assume that an HTTP/3 implementation could have certain API to request this padding and what behavior it has . However , can this be anything other than generally padding out the QUIC connection . I think from this level it might be hard to have any more detailed control over where the padding data goes . The QUIC scheduler will do what it is programmed to do when it has multiple streams to send and split that into different packets in an implementation dependent fashion . So I wonder what impression people get of this padding feature ? It appears hard to use for privacy preserving features as that needs to more consistently ensure that an outside observer ca n't detect patterns . So it will basically be for keep - alive and consuming more bits , possibly to probe if the application can take the step to the next quality level . So I would think the properties of this should be slightly more explained to not give false hopes . 
 HTTP traffic patterns can be quite bursty with a lot of cessation . The possible privacy preserving feature comes from an endpoint that can continue to drive application traffic over some time window . Allowing an application to pump the QUIC connection , and have the transport just deal with it without any special configuration seems attractive . In other words , if the transport is not application - limited then it can always keep the congestion window full . A scheduler can always demote such streams to behind all other streams . However , a receiver that does n't immediately drain such streams will cause app limitation , which could affect the privacy targets . We might want to document that . 
 Ok that is one aspect that would benefit from clarification . I think some words on the properties that application level requested usage of reserved stream has would also be good . 
 does the PR address your issue ? 
 This is editorial because we 're just explaining a bit more how an endpoint might use what HTTP/3 provides . 
 Yes , this I think provides sufficient context for the padding and combined with the risks of applying it badly . So resolved .
Paragraph (version A):
Where HTTP/2 employs PADDING frames and Padding fields in other
frames to make a connection more resistant to traffic analysis,
HTTP/3 can either rely on transport-layer padding or employ the
reserved frame and stream types discussed in frame-reserved and
stream-grease.  These methods of padding produce different results in
terms of the granularity of padding, how padding is arranged in
relation to the information that is being protected, whether padding
is applied in the case of packet loss, and how an implementation
might control padding.  Redundant padding could even be
counterproductive.
Paragraph (version A):
Use of padding can result in less protection than might seem
immediately obvious.  At best, padding only makes it more difficult
for an attacker to infer length information by increasing the number
of frames an attacker has to observe.  Incorrectly implemented
padding schemes can be easily defeated.  In particular, randomized
padding with a predictable distribution provides very little
protection; similarly, padding payloads to a fixed size exposes
information as payload sizes cross the fixed-sized boundary, which
could be possible if an attacker can control plaintext.
Paragraph (version B):
Where HTTP/2 employs PADDING frames and Padding fields in other
frames to make a connection more resistant to traffic analysis,
HTTP/3 can either rely on transport-layer padding or employ the
reserved frame and stream types discussed in frame-reserved and
stream-grease.  These methods of padding produce different results in
terms of the granularity of padding, how padding is arranged in
relation to the information that is being protected, whether padding
is applied in the case of packet loss, and how an implementation
might control padding.
Paragraph (version B):
Reserved stream types can be used to give the appearance of sending
traffic even when the connection is idle.  Because HTTP traffic often
occurs in bursts, apparent traffic can be used to obscure the timing
or duration of such bursts, even to the point of appearing to send a
constant stream of data.  However, as such traffic is still flow
controlled by the receiver, a failure to promptly drain such streams
and provide additional flow control credit can limit the sender's
ability to send real traffic.
Paragraph (version B):
Use of padding can result in less protection than might seem
immediately obvious.  Redundant padding could even be
counterproductive.  At best, padding only makes it more difficult for
an attacker to infer length information by increasing the number of
frames an attacker has to observe.  Incorrectly implemented padding
schemes can be easily defeated.  In particular, randomized padding
with a predictable distribution provides very little protection;
similarly, padding payloads to a fixed size exposes information as
payload sizes cross the fixed-sized boundary, which could be possible
if an attacker can control plaintext.