Re: PRISM and HTTP/2.0

Amos Jeffries <squid3@treenet.co.nz> Tue, 16 July 2013 12:22 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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650A421F9A17 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 16 Jul 2013 05:22:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.566
X-Spam-Level:
X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 OAW7bxdA+neW for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 16 Jul 2013 05:22:23 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEA221F9EDF for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 16 Jul 2013 05:22:14 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Uz4FV-0008S7-W7 for ietf-http-wg-dist@listhub.w3.org; Tue, 16 Jul 2013 12:20:58 +0000
Resent-Date: Tue, 16 Jul 2013 12:20:57 +0000
Resent-Message-Id: <E1Uz4FV-0008S7-W7@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 1Uz4FM-0008R5-Fc for ietf-http-wg@listhub.w3.org; Tue, 16 Jul 2013 12:20:48 +0000
Received: from ip-58-28-153-233.static-xdsl.xnet.co.nz ([58.28.153.233] helo=treenet.co.nz) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1Uz4FL-0005HO-BB for ietf-http-wg@w3.org; Tue, 16 Jul 2013 12:20:48 +0000
Received: from [192.168.1.218] (ip202-27-218-168.satlan.co.nz [202.27.218.168]) by treenet.co.nz (Postfix) with ESMTP id 262DCE6EAF for <ietf-http-wg@w3.org>; Wed, 17 Jul 2013 00:20:20 +1200 (NZST)
Message-ID: <51E53A7D.4090306@treenet.co.nz>
Date: Wed, 17 Jul 2013 00:20:13 +1200
From: Amos Jeffries <squid3@treenet.co.nz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: ietf-http-wg@w3.org
References: <5672.1373710085@critter.freebsd.dk> <51E1D7AF.20708@jrn.me.uk> <CALvhUEW87qGoCYAPY_DW37bs4P=maD0iWFk6tWc-ZVN15KUWtg@mail.gmail.com>
In-Reply-To: <CALvhUEW87qGoCYAPY_DW37bs4P=maD0iWFk6tWc-ZVN15KUWtg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=58.28.153.233; 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.449, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1Uz4FL-0005HO-BB 9add1eadf2ab74a9e49a9652a6cc5618
X-Original-To: ietf-http-wg@w3.org
Subject: Re: PRISM and HTTP/2.0
Archived-At: <http://www.w3.org/mid/51E53A7D.4090306@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18805
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/07/2013 4:19 a.m., Reto Bachmann-Gmür wrote:
> On Sun, Jul 14, 2013 at 12:41 AM, J Ross Nicoll wrote:
>> Bogus certificates and server-side backdoors seem inevitable, at least in
>> the current political climate. I don't think any realistic changes at the
>> transport layer will affect that (unrealistic changes would include "move to
>> a web of trust").
> Not sure if it would be within the possibilities of this WG to define
> an optional public key hash in HTTP URIs. If a link contains such a
> hash of the public key of the target this would protect against
> attacks from a root-certificate holding man in the middle.

I can't think how. The MITM can as easily change that public key to its 
own one and use the original itself as the client could use it in the 
first place. Security 101 - never send the vital key data over a suspect 
channel which relys on that key for protection.

The whole of this thread is beyond WG charter IMHO. Let us stop circling 
the drain on it.

Amos