Re: h2 padding

On 4 September 2014 15:48, Greg Wilkins <gregw@intalio.com> wrote:
> I cannot see how we are going to test that applications actually implement
> such requirements anyway.

Don't set the perfect as the enemy of the good.  Many security
decisions are - at first assessment - difficult to test on these
grounds, but please don't extrapolate from seemingly hard to
impossible.

Rather than contemplate the infinite and byzantine complexity that
might arise, perhaps it would help to demonstrate how a feature like
this could provide security.  As has been discussed, Twitter pad
profile images so that it is hard for a passive observer to use
traffic analysis to determine which profile has been accessed by a
given user.  I don't know the specifics, but the idea being that you
might reveal that you are accessing a profile, but individual requests
don't leak details because they now enjoy k-anonymity with a very
large k.  The same process has been used in other places to avoid
side-channel leaks like that.

Now, it's true that Twitter are probably just padding the images
themselves, exploiting the fact that lossy compression can be made
arbitrarily un-lossy.  But that general technique might not apply to
other types of resource.  And expanding the file size has negative
effects on the space that resources use in caches and other things.
It's marginally more efficient to pad at the protocol layer.  TLS
padding is an option, but it's more limited in scope and it might not
be accessible.

Determining the set of resources that you want to provide anonymity
within is easy.  Determining the range of sizes over which you need to
operate is easy.  Padding to the maximum size of that set is easy.
Determining that this is the thing you need to protect in order to
ensure that you haven't leaked critical information...well...

Received on Thursday, 4 September 2014 23:10:29 UTC