Re: h2 padding

On Sep 2, 2014, at 11:07 PM, Brian Smith wrote:

> On Tue, Sep 2, 2014 at 10:36 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> 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.
> 
> Consider an implementation that sends every frame in its own TCP
> packet, perhaps with a 1 minute delay between frames. Such an
> implementation would conform to Roy's suggestion, but it would
> partially or completely defeat the purpose of the padding.

Perhaps it will help if we clarify the assumptions here.  The first is
that the application is adding padding for a reason and not simply because
it is cool.  The second is that the rate at which they send data is under
their control, along with how that data is arranged in h2 padded form.
Deliberately sending h2 padding in a form that defeats its purpose is not
a design consideration.

> To make the
> change that Roy suggested safe(r), there would have to be the
> additional restriction that a padding frame and the frame it is
> associated with are not split this way. This seems like a difficult
> thing to formulate. More importantly, it seems extremely error-prone
> and thus it would be a counterproductive change in terms of security.

No.  There is no need to require that cars be unable to change lanes
just because some driver might be drunk at the wheel. Absolute security is
not a design goal.  It is sufficient to design a protocol that can be used
for a given purpose when that purpose is understood.

> Note that the current draft doesn't prohibit an implementation from
> sending the padding part of a DATA frame in one packet and the actual
> data part in a separate packet, with our without delays between them.
> Similarly, it seems like a proxy is allowed to split a DATA frame into
> two DATA frames and/or coalesce them together. The draft needs to be
> updated to prohibit any such special processing of the padding
> distinctly from the actual data. Regardless, this should be easier to
> formulate for the current single-frame situation than it would be with
> Roy's separate-frame proposal.

Not at all.  And, no, the draft does not need to forbid bad implementations
of padding.  Warning against them is okay.

> It would also be more difficult to reformulate the requirement "All
> implementations MUST be capable of receiving and minimally processing
> frames up to 2^14 octets in length, plus the 9 octet frame header
> (Section 4.1)" to work with a separate padding frame. (I hope the
> reason is obvious; if not, I can explain more.)

No, it makes no difference whatsoever.  If the requirement was that they
only be able to process exactly 2^14 octets and you assume that an attacker
can inject 2^14 octets into the data without being detected, then something
might break somewhere.  However, there is nothing to suggest that the
break would have anything to do with a frame boundary.  For both the
current spec and any suggested changes, padding only works if both
the data and padding are written to the network in the same way, without
any difference at the padding boundaries, and they are both subject to
flow control in the same way.  An application with enough control over
h2 to generate h2 padding will also be capable of managing the amount
of data placed in each h2 frame.

> I actually think it is worth evaluating whether the padding mechanism
> is practically useful as a security mechanism as specified and with
> the above issues addressed. Has anybody actually used frame padding to
> solve a real-world problem yet? Has anybody tried to write a
> terrible-but-conforming implementation that effectively undoes all the
> protection that padding is supposed to offer? It seems likely that the
> answer to both questions is "no."
> 
> tl;dr: The more the specification treats the padding bytes as being
> equivalent and indistinguishable from the actual frame payload, the
> more secure the padding mechanism will be. Putting the padding in a
> separate frame is completely at odds with this. There are problems
> with how padding is specified, but the padding being in the same frame
> as the data is not one.

I think you are assuming there is some magic boundary between frames
other than the length delimitation.  There is none.  An application can
write two frames just as easily as it can write one frame with optional
pad length and optional padding at the end.  The only difference is
where the overhead occurs.

If I thought that anyone would use padding on a regular basis, then
I would make the pad-length part of a fixed frame header that everyone
has to send.  My suggestion to use separate padding frames is partly
because I don't think it will be used at all, or at least only under
very specific circumstances that can justify the overhead.

....Roy

Received on Wednesday, 3 September 2014 20:12:58 UTC