Re: h2 padding

On 30 Aug 2014, at 10:14 pm, Roy T. Fielding <fielding@gbiv.com> wrote:

> This comment is in reference to sections 6.1, 6.2, 6.6 of
> 
> http://tools.ietf.org/id/draft-ietf-httpbis-http2-14.txt
> 
>> 6.1.  DATA
>> 
>>   DATA frames (type=0x0) convey arbitrary, variable-length sequences of
>>   octets associated with a stream.  One or more DATA frames are used,
>>   for instance, to carry HTTP request or response payloads.
>> 
>>   DATA frames MAY also contain arbitrary padding.  Padding can be added
>>   to DATA frames to obscure the size of messages.
>> 
>>     0                   1                   2                   3
>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |Pad Length? (8)|
>>    +---------------+-----------------------------------------------+
>>    |                            Data (*)                         ...
>>    +---------------------------------------------------------------+
>>    |                           Padding (*)                       ...
>>    +---------------------------------------------------------------+
>> 
>>                            DATA Frame Payload
>> 
>>   The DATA frame contains the following fields:
>> 
>>   Pad Length:  An 8-bit field containing the length of the frame
>>      padding in units of octets.  This field is optional and is only
>>      present if the PADDED flag is set.
>> 
>>   Data:  Application data.  The amount of data is the remainder of the
>>      frame payload after subtracting the length of the other fields
>>      that are present.
>> 
>>   Padding:  Padding octets that contain no application semantic value.
>>      Padding octets MUST be set to zero when sending and ignored when
>>      receiving.
> 
> I think that is a mistake.  Forcing padding to zero makes it less random
> and causes it to be compressed to nothing if a higher layer compresses
> the stream.  A requirement on senders cannot prevent bad actors from
> sending non-zeros (assuming this is to prevent smuggling of data).

Raised as <https://github.com/http2/http2-spec/issues/602>.


> 
>>   The DATA frame defines the following flags:
>> 
>>   END_STREAM (0x1):  Bit 1 being set indicates that this frame is the
>>      last that the endpoint will send for the identified stream.
>>      Setting this flag causes the stream to enter one of the "half
>>      closed" states or the "closed" state (Section 5.1).
>> 
>>   PADDED (0x8):  Bit 4 being set indicates that the Pad Length field is
>>      present.
>> 
>>   DATA frames MUST be associated with a stream.  If a DATA frame is
>>   received whose stream identifier field is 0x0, the recipient MUST
>>   respond with a connection error (Section 5.4.1) of type
>>   PROTOCOL_ERROR.
>> 
>>   DATA frames are subject to flow control and can only be sent when a
>>   stream is in the "open" or "half closed (remote)" states.  The entire
>>   DATA frame payload is included in flow control, including Pad Length
>>   and Padding fields if present.  If a DATA frame is received whose
>>   stream is not in "open" or "half closed (local)" state, the recipient
>>   MUST respond with a stream error (Section 5.4.2) of type
>>   STREAM_CLOSED.
>> 
>>   The total number of padding octets is determined by the value of the
>>   Pad Length field.  If the length of the padding is greater than the
>>   length of the remainder of the frame payload, the recipient MUST
>>   treat this as a connection error (Section 5.4.1) of type
>>   PROTOCOL_ERROR.
>> 
>>   Note:  A frame can be increased in size by one octet by including a
>>      Pad Length field with a value of zero.
>> 
>>   Use of padding is a security feature; as such, its use demands some
>>   care, see Section 10.7.
> 
> I think there is a misunderstanding here.  Padding is used to allow an
> opaque stream to not reveal its size.  Frames are not opaque.  There is no
> need for padding within a frame.  The security need is for padding to be
> allowed after a frame when both are enveloped within an opaque stream.
> 
> Naturally, this is best accomplished with a padding frame type.
> 
> As you can see, almost half of the description of this frame is devoted
> to the optional padding.  The same is true of 6.2 and 6.6.
> By moving padding to a frame type, we can then remove the optional
> pad length and half the complexity for each of the types that currently
> allow padding within their frames.

This doesn’t appear to affect interoperability or security; you’re basically saying “I wouldn’t have done it that way.”

We can certainly still change the way padding is done, but I need to see consensus in the WG that doing so is necessary. 

What do people think of Roy’s subsequent proposal to have a separate padding frame and always send it? Please be aware that changing the padding scheme would necessitate another round of security review.

I’m assuming that by “always send it”, you mean that a padding frame should be sent every time a potentially paddable frame is sent, correct? Note that this would effectively double the overhead of the frame header.

Regards,


--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 3 September 2014 05:37:26 UTC