Re: h2 padding

On Wed, Sep 3, 2014 at 3:45 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 3 September 2014 15:31, Brian Smith <brian@briansmith.org> wrote:
>> But, draft 14 doesn't say that.
>
> Woah nelly, we don't mandate that for a number of reasons.
>
> Firstly, because of what Roberto said.  Sometimes padding is added for
> the purposes of enhancement.  For instance, we might have two backends
> that might perform their own padding, but there might be resources
> from each of those that we want to ensure are indistinguishable.  A
> reverse proxy can add padding to ensure that.  That sort of additive
> padding only increases the size of the anonymity set, which can't be
> worse (though it may not be better, certainly.)
>
> Similarly, a proxy serving many clients might want to prevent
> length-based correlation between client-side and origin-server-side
> exchanges by adding padding.
>
> We don't want to prohibit those cases.  Generally speaking, the people
> making the changes know better than we do.  Therefore, we use a SHOULD
> and recommend that intermediaries not remove padding.

Draft 14 says:

   Padding can be used to obscure the exact size of frame content, and
   is provided to mitigate specific attacks within HTTP.  For example,
   attacks where compressed content includes both attacker-controlled
   plaintext and secret data (see for example, [BREACH]).

My comments are directed at the use of padding as a mitigation against
attacks like BREACH--i.e. the attacks for which the padding mechanism
"is provided to migitate." It seems like, with the way padding is
currently specified, no endpoint can rely on it to mitigate
BREACH-type attacks, for the reasons I gave. If that is intended, then
the security considerations section of the draft should be fixed to
indicate that, as right now it is very misleading.

The other text in the security considerations seems intended to
discourage the other possible uses of padding that you mention in your
email above. If that isn't intended then it should be clarified too.

>> So, we have to assume some implementations will choose to split
>> the data stream at the frame boundary.
>
> Let us be very careful to distinguish between potentially more secure
> because we are providing the necessary tools and more secure even when
> people do the wrong thing.  We're not aiming for the latter here.

Splitting at the frame boundary is not specified as the wrong thing
anywhere in the draft. And, isn't it very likely that many or even
most implementations will try to do that? In particular, it seems like
a good performance optimization to size TLS records to reduce or
minimize the number of split frames in a record, at least for some
endpoints, which would be the wrong thing to do with separate padding
frames.

Cheers,
Brian

Received on Wednesday, 3 September 2014 22:59:56 UTC