Re: h2 padding

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/09/2014 12:25 p.m., Martin Thomson wrote:
> On 3 September 2014 15:59, Brian Smith wrote:
>> 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 you use TLS end-to-end, without intermediation, I see no reason 
> that this can't be used to mitigate BREACH (or CRIME) attacks and 
> their ilk.  Certainly in cases where translation to HTTP/1.1
> occurs, that might not be true.

Assuming the BREACH (or CRIME) vulnerability exists in the TLS. The
use of TLS with the vulnerability is forbidden elsewhere in h2.


The multiplexing itself can potentially be a far more effective
discouragement against timing and power consumption attacks, since any
particular data or CPU fluctuation could be from any stream with
arbitrary DATA payload slicings.

Essentially streams 1 through n-1 and streams n+1 through 2^31-1, all
perform the same duty as random padding on stream n when the
connection is tunneled *in any way* (including TLS wrapped). Only they
do so with non-zero octets and random amounts of work to generate the
unrelated framing, which itself is better protection than padding
using nil octets could ever be.


On a related note, this muxing-vs-nil-padding benefit is gained most
prominently when a proxy is used since the streams there are also
muxed across origins. Padding has the upper hand on single-hop
connections, muxing on shared proxy connections.
 The mandate on proxies to keep padded traffic as a special case just
to preserve padding effectively forces a special connection and code
paths to be used for it, which potentially isolates and highlights it
for the observing attacker.


> 
>>>> 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.
> 
> Nor is sticking your head out of a moving subway carriage.

Except on subways where it is relevant.

The discussion was about splitting of DATA frames. How to split a
frame with DATA+padding ? ... drop the padding and split is the
obvious option, both simple and fast code. With no reasons speciying
otherwise that is what will be widely implemented.

Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUB8xnAAoJELJo5wb/XPRjFUcIAMLERrTQa0sFUJ2DwjGUxGtJ
2Cia6E/S6gyI9wTCXig1sFQOU4Mh75QVgemvnOXIQyaVOf7kTFINV2pEDsUEtKsd
1u/KklgNHqJRFikkwYCk5YjsmI7VKnqv/61hKX4VKAr2R9b4LB0vIW093uqLU+0d
xV/7J8TaEW0iUz02+StfgxjAvr2+1ijTyuYl0by06dIZNwpuFmCa0EUdZfLsMBjo
2HuzdiFciuRWPcf9tiXpzSXSz1OiL/M0j566VVoO1AvLCA13qqxC6Tlt4N/jpmBb
tqTONdhFSoYFRaIhdQLsYa9N55/hvtlpl5MQxQHnvXiKroDRG16D/9xnhBB2j2U=
=/3bj
-----END PGP SIGNATURE-----

Received on Thursday, 4 September 2014 02:20:59 UTC