IETF Logo Mail Archive

Re: [perpass] Unauthenticated, ephemeral keying in HTTP/1.0 without TLS

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 17 November 2013 03:27 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2851F11E821A for <perpass@ietfa.amsl.com>; Sat, 16 Nov 2013 19:27:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAqdP+Eo9M1N for <perpass@ietfa.amsl.com>; Sat, 16 Nov 2013 19:27:53 -0800 (PST)
Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 11AFD11E821B for <perpass@ietf.org>; Sat, 16 Nov 2013 19:27:52 -0800 (PST)
Received: by mail-pd0-f178.google.com with SMTP id p10so5099972pdj.37 for <perpass@ietf.org>; Sat, 16 Nov 2013 19:27:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7R59v0HkZMtVgJdvrD68rj4g3t2nWexU4Ug6rex5RDc=; b=T8MHUSy7P2n+9o5oMnALoT0mJZTqCsAC/DBcGNEsDysy/3mf7d5MCdc3gdA1qpC8w6 mgp3bimNQZ7UFCQl/dKpEvrhRHo7Myi+u64xEAT1ocZBzGeJve/JGA/HsD8Wu97aU8FV vnyYwLK2YTaA8cL2Jdi05/Y4yz8+yPt9fXVku2JDxxwgrpAc5WKuXpen32y71qCR7Ntf IRtKWqY23kHDozcbtl0aCnQ+Gb+1zlClQ71vSl1ROgeIre4/PxzKCwHioLBTkx1i0tpt HFfw58t1H+CszkoeYuVHCbuLef/feRexEVDcONt02Glq5MhflubbNmeSXSfcWYeIAimz 7p3A==
X-Received: by 10.66.142.170 with SMTP id rx10mr14542774pab.117.1384658871785; Sat, 16 Nov 2013 19:27:51 -0800 (PST)
Received: from [192.168.178.20] (151.199.69.111.dynamic.snap.net.nz. [111.69.199.151]) by mx.google.com with ESMTPSA id ka3sm14249513pbc.32.2013.11.16.19.27.49 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Nov 2013 19:27:50 -0800 (PST)
Message-ID: <528837B4.7000601@gmail.com>
Date: Sun, 17 Nov 2013 16:27:48 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ted Lemon <mellon@fugue.com>
References: <CAMm+Lwg-AF9fZ5=f5W8JDmiCe=U7Uyxso_bdHGaQhddsQ+aGaw@mail.gmail.com> <5287FA09.3060100@gmail.com> <C6822D2B-DE14-43FF-A2D4-F96941F054B7@fugue.com>
In-Reply-To: <C6822D2B-DE14-43FF-A2D4-F96941F054B7@fugue.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: perpass <perpass@ietf.org>, Phillip Hallam-Baker <hallam@gmail.com>
Subject: Re: [perpass] Unauthenticated, ephemeral keying in HTTP/1.0 without TLS
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Nov 2013 03:27:54 -0000

On 17/11/2013 12:51, Ted Lemon wrote:
> On Nov 16, 2013, at 6:04 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>> Indeed. A "solution" in which caches, proxies, content filtering
>> and possibly CDNs don't work is not going to be deployed on any Internet
>> on this planet.
> 
> Er, be careful here.   It's certainly true that a solution that prevents CDNs, caches, proxies and content filtering from working won't see rapid uptake among providers that depend on these capabilities.   However, there is a rather substantial long tail of web sites that do not depend on these capabilities and never will, and it is these very web sites for which the ability to do various kinds of passive tracking will be most useful, because they say the most about you.

Well yes, but the hypothesis seemed to be TLS on *every* HTTP connection.
That doesn't seem to fly, is my point (and, I think, Phill's).

> Also, to completely contradict that point, facebook with https enabled still uses a CDN, so the theory that https prevents CDNs from working is apparently wrong anyway.

I said "possibly" because I wasn't sure. Maybe somebody can explain
how it works and how the associated trust model works?

    Brian

v2.23.0 | Report a Bug | By Email