Re: HTTP/2 and Pervasive Monitoring

On 16/08/2014 10:36 p.m., Stephen Farrell wrote:
> On 16/08/14 07:20, Poul-Henning Kamp wrote:
>> --------
>> In message <>, Stephen Farrell writes:
>>> PHK and I disagree a bit about the definition of PM in that respect.
>>> I conclude that BCP188 would include storing breakable ciphertext in
>>> the definition of PM. He doesn't.
>> Stephen, you're free to express your own opinion, but I think it
>> would be best if you let me express mine.
> Apologies. I should have said "I think he doesn't".
> ...
>> The important thing in my straw-man is not if we should or shouldn't
>> do it, but the fact that PM can be made impossible with ciphersuites
>> you can break in a matter of seconds.
> That last is the part with which I disagree. I just don't think its
> true, for what I understand as PM, as defined in BCP188.
> But I agree with you about the rest, that is, if you said chacha20
> and not breakable-cipher then we'd be saying the same thing.
> Cheers,
> S

I'd like to know what your particular reasons for disagreement are.

For my part, I do not believe that timing assertions in the argument are
sufficiently long.

- 250ms is only the normal network lag of a connection from my home to a
Canadian server (150-250 is normal for NZL). E.g. anyone over here in NZ
using the free Google DNS services routinely see that much delay.
Several such delays for displaying modern pages is not seen as any, or
much, impedence.

- The Human-Computer Interface rule of thumb still has 5 seconds of
delay being the *lower* limit on user patience. And that is for users
who sit and wait for the loading**. In my experience they are tending to
use tabs now and observe one while others load.

 ** I am assuming here that the XHR/AJAX type background traffic on
interactive pages is re-using existing connection(s) to the server (ie
over h2, or long-polling). Such connections only the initial MITM delay
on decrypting the first bytes to identify keys matters.


Received on Sunday, 17 August 2014 05:45:54 UTC