h2 padding

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).

>    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.


Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <http://www.adobe.com/>

Received on Saturday, 30 August 2014 19:14:36 UTC