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

Ted Lemon <mellon@fugue.com> Sun, 17 November 2013 03:54 UTC

Return-Path: <mellon@fugue.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 7C6BB11E8454 for <perpass@ietfa.amsl.com>; Sat, 16 Nov 2013 19:54:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.378
X-Spam-Level:
X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599]
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 vLDIr16pB8Ru for <perpass@ietfa.amsl.com>; Sat, 16 Nov 2013 19:54:43 -0800 (PST)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3C80A11E8453 for <perpass@ietf.org>; Sat, 16 Nov 2013 19:54:09 -0800 (PST)
Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 7716023824DE; Sat, 16 Nov 2013 22:54:07 -0500 (EST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <528837B4.7000601@gmail.com>
Date: Sat, 16 Nov 2013 22:54:05 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <DF3E18C6-4F1C-4EFC-ABDF-8756C886A6EB@fugue.com>
References: <CAMm+Lwg-AF9fZ5=f5W8JDmiCe=U7Uyxso_bdHGaQhddsQ+aGaw@mail.gmail.com> <5287FA09.3060100@gmail.com> <C6822D2B-DE14-43FF-A2D4-F96941F054B7@fugue.com> <528837B4.7000601@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1822)
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:54:49 -0000

On Nov 16, 2013, at 10:27 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 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).

I don't see it.  Sure, for transparent caching it won't work, but are people still using transparent caching for CDN?   Clearly facebook isn't, nor Google.   I think this ship has already flown the coop.

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

The web page you download using https from facebook lists content on cdn URLs.   The browser connects to the cdn server and fetches each such URL.   The URLs on the facebook page I looked at are all https.   Why wouldn't this just work?   Transparent caching would break, but that's not what's going on here—this is not at all transparent.