Re: HTTP/2 and Pervasive Monitoring

Mark Nottingham <mnot@mnot.net> Fri, 15 August 2014 11:29 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 4C7031A09EE for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 15 Aug 2014 04:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.57
X-Spam-Level:
X-Spam-Status: No, score=-7.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4jyyC-FAna48 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 15 Aug 2014 04:29:39 -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 6C5C31A09ED for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 15 Aug 2014 04:29:39 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1XIFeP-0007aH-SV for ietf-http-wg-dist@listhub.w3.org; Fri, 15 Aug 2014 11:26:29 +0000
Resent-Date: Fri, 15 Aug 2014 11:26:29 +0000
Resent-Message-Id: <E1XIFeP-0007aH-SV@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1XIFe5-0007ZU-JN for ietf-http-wg@listhub.w3.org; Fri, 15 Aug 2014 11:26:09 +0000
Received: from mxout-08.mxes.net ([216.86.168.183]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1XIFe1-0000qa-6J for ietf-http-wg@w3.org; Fri, 15 Aug 2014 11:26:09 +0000
Received: from [192.168.1.55] (unknown [118.209.12.212]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8C93E509B6; Fri, 15 Aug 2014 07:25:40 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <4851.1408094168@critter.freebsd.dk>
Date: Fri, 15 Aug 2014 21:25:36 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EB5B7C64-165B-48F1-94FF-1354E917A10F@mnot.net>
References: <38BD57DB-98A9-4282-82DD-BB89F11F7C84@mnot.net> <4851.1408094168@critter.freebsd.dk>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
X-Mailer: Apple Mail (2.1878.6)
Received-SPF: pass client-ip=216.86.168.183; envelope-from=mnot@mnot.net; helo=mxout-08.mxes.net
X-W3C-Hub-Spam-Status: No, score=-3.8
X-W3C-Hub-Spam-Report: AWL=-3.074, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1XIFe1-0000qa-6J 3aff8e5fee0f1e4487c23c7f0863c079
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 and Pervasive Monitoring
Archived-At: <http://www.w3.org/mid/EB5B7C64-165B-48F1-94FF-1354E917A10F@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/26610
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>

Hi PHK,

On 15 Aug 2014, at 7:16 pm, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> Straw-man:
> ----------
> 
> 	http:/ can use TLS with *arbitrarily weak* crypto algorithms,
> 	and no authentication, and it is treated *exactly* like
> 	HTTP/1.1 plaintext by browsers.
> 
> 	https:/ uses authenticated TLS with strong crypto, as today,
> 	and indicates this with the well-known changes in browser
> 	behaviour.

It sounds like you're proposing that we allow weaker ciphersuites for the Opp-Sec draft. 

That hasn't been discussed explicitly before IIRC, but it shares an issue that we did previously discuss; if you're not authenticating the Opp-Sec traffic, you want it to look as much like "real" TLS traffic as possible, so that an attacker doesn't know which connections it can MITM without being caught. 

If Opp-Sec traffic is able to be distinguished (e.g., by using a different ciphersuite), it'll be possible for an active attacker to selectively MITM it and not be detected. 

The trade-off of the extra efficiency gained vs. the loss of protection is debatable from both sides, of course.

Cheers,

--
Mark Nottingham   https://www.mnot.net/