Re: HTTP/2 and Pervasive Monitoring
Amos Jeffries <squid3@treenet.co.nz> Sun, 17 August 2014 05:49 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FAB1A0729 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 16 Aug 2014 22:49:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.17
X-Spam-Level:
X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yfC9fXfMg0A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 16 Aug 2014 22:49:42 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC0B1A0727 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 16 Aug 2014 22:49:42 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1XItIO-0006eC-Gh for ietf-http-wg-dist@listhub.w3.org; Sun, 17 Aug 2014 05:46:24 +0000
Resent-Date: Sun, 17 Aug 2014 05:46:24 +0000
Resent-Message-Id: <E1XItIO-0006eC-Gh@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1XItHu-0005B7-9s for ietf-http-wg@listhub.w3.org; Sun, 17 Aug 2014 05:45:54 +0000
Received: from 121-99-228-82.static.orcon.net.nz ([121.99.228.82] helo=treenet.co.nz) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1XItHs-0007PZ-Qp for ietf-http-wg@w3.org; Sun, 17 Aug 2014 05:45:54 +0000
Received: from [192.168.2.97] (unknown [203.184.52.78]) by treenet.co.nz (Postfix) with ESMTP id 6DA54E6E37 for <ietf-http-wg@w3.org>; Sun, 17 Aug 2014 17:45:21 +1200 (NZST)
Message-ID: <53F04169.1050507@treenet.co.nz>
Date: Sun, 17 Aug 2014 17:45:13 +1200
From: Amos Jeffries <squid3@treenet.co.nz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: ietf-http-wg@w3.org
References: <38BD57DB-98A9-4282-82DD-BB89F11F7C84@mnot.net> <CAH_y2NFr16YJEsN-=zUWjEdywuLpuOVijFmybjbXZtAE4LTMdg@mail.gmail.com> <DE8B5174-864A-4514-B2DC-6F1742535A8C@mnot.net> <CAH_y2NHOspsVugNZZgvD3XMZ522PzNkTRMS1dapcRDWQCL5ZsQ@mail.gmail.com> <8622.1408147394@critter.freebsd.dk> <53EEA563.4020703@cs.tcd.ie> <9932.1408170013@critter.freebsd.dk> <53EF3419.60207@cs.tcd.ie>
In-Reply-To: <53EF3419.60207@cs.tcd.ie>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=121.99.228.82; envelope-from=squid3@treenet.co.nz; helo=treenet.co.nz
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-3.450, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_RCVD_IP=0.001
X-W3C-Scan-Sig: maggie.w3.org 1XItHs-0007PZ-Qp 609077c6d67847aa645ff4b14faeafbb
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 and Pervasive Monitoring
Archived-At: <http://www.w3.org/mid/53F04169.1050507@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/26632
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
On 16/08/2014 10:36 p.m., Stephen Farrell wrote: > > > On 16/08/14 07:20, Poul-Henning Kamp wrote: >> -------- >> In message <53EEA563.4020703@cs.tcd.ie>, 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. Amos
- HTTP/2 and Pervasive Monitoring Mark Nottingham
- Re: HTTP/2 and Pervasive Monitoring Amos Jeffries
- Re: HTTP/2 and Pervasive Monitoring Greg Wilkins
- RE: HTTP/2 and Pervasive Monitoring K.Morgan
- Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp
- Re: HTTP/2 and Pervasive Monitoring Mark Nottingham
- Re: HTTP/2 and Pervasive Monitoring Mark Nottingham
- Re: HTTP/2 and Pervasive Monitoring Eliot Lear
- Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp
- Re: HTTP/2 and Pervasive Monitoring Martin Nilsson
- Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp
- RE: HTTP/2 and Pervasive Monitoring Albert Lunde
- Re: HTTP/2 and Pervasive Monitoring Cory Benfield
- Re: HTTP/2 and Pervasive Monitoring Erik Nygren
- Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp
- Re: HTTP/2 and Pervasive Monitoring Roland Zink
- Re: HTTP/2 and Pervasive Monitoring Martin Thomson
- Re: HTTP/2 and Pervasive Monitoring Brian Smith
- Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp
- Re: HTTP/2 and Pervasive Monitoring Eliot Lear
- Re: HTTP/2 and Pervasive Monitoring Greg Wilkins
- Re: HTTP/2 and Pervasive Monitoring Greg Wilkins
- Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp
- Re: HTTP/2 and Pervasive Monitoring Stephen Farrell
- Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp
- Re: HTTP/2 and Pervasive Monitoring Roland Zink
- Re: HTTP/2 and Pervasive Monitoring Stephen Farrell
- Re: HTTP/2 and Pervasive Monitoring Amos Jeffries
- Re: HTTP/2 and Pervasive Monitoring Eliot Lear
- Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp
- Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp
- Re: HTTP/2 and Pervasive Monitoring Ilari Liusvaara
- Re: HTTP/2 and Pervasive Monitoring Mark Nottingham
- Re: HTTP/2 and Pervasive Monitoring Greg Wilkins
- Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp
- Re: HTTP/2 and Pervasive Monitoring Martin Thomson
- Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp
- Re: HTTP/2 and Pervasive Monitoring Martin Thomson
- Re: HTTP/2 and Pervasive Monitoring Poul-Henning Kamp