Re: h2 padding

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

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.

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

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.

Cheers,
Brian

Received on Wednesday, 3 September 2014 06:08:11 UTC