Re: [saag] Ubiquitous Encryption: content filtering

Nico Williams <nico@cryptonector.com> Mon, 22 June 2015 21:46 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFCA1A01FC for <saag@ietfa.amsl.com>; Mon, 22 Jun 2015 14:46:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.233
X-Spam-Level:
X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 dHlXkQ3ZOIoR for <saag@ietfa.amsl.com>; Mon, 22 Jun 2015 14:46:54 -0700 (PDT)
Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A48A71A011D for <saag@ietf.org>; Mon, 22 Jun 2015 14:46:54 -0700 (PDT)
Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 7A22D202047; Mon, 22 Jun 2015 14:46:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=elukEHf2q8dnSI LzaTIIA1eLV/U=; b=WADWvfzFqZjRS3YGnV5h+/fEarQw16FsrOos9ELk25hpcg Wrb/Txn0Q9KInEXZ2Hqdlw+kMugQFf0gwAz+jygkM565hyHRZ4J/PsEcsLU3EhO6 yUb4VuaQoTRpDu2dzdYIBUdxFs9MlwzrJq8LBlrhYWZUWqfEceDKSqUZOg2yk=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPA id 866E5202015; Mon, 22 Jun 2015 14:46:53 -0700 (PDT)
Date: Mon, 22 Jun 2015 16:46:51 -0500
From: Nico Williams <nico@cryptonector.com>
To: Christian Huitema <huitema@microsoft.com>
Message-ID: <20150622214650.GN6117@localhost>
References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> <CABtrr-U9kLfq4GQbWSgPN=wCD=Cdi0uQ+bQqXj35j+PFtuE8Pg@mail.gmail.com> <A4BAAB326B17CE40B45830B745F70F108E070156@VOEXM17W.internal.vodafone.com> <55844743.4030300@cs.tcd.ie> <55886F38.4030906@bbn.com> <20150622211207.GM6117@localhost> <DM2PR0301MB06554ECDB1166C32CF70366CA8A10@DM2PR0301MB0655.namprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <DM2PR0301MB06554ECDB1166C32CF70366CA8A10@DM2PR0301MB0655.namprd03.prod.outlook.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/u9HzvbvIxKawdfWz4xcw1mn8emM>
Cc: "saag@ietf.org" <saag@ietf.org>
Subject: Re: [saag] Ubiquitous Encryption: content filtering
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jun 2015 21:46:55 -0000

On Mon, Jun 22, 2015 at 09:24:04PM +0000, Christian Huitema wrote:
> On Monday, June 22, 2015, at 2:12 PM, Nico Williams wrote:
> > ..
> > But it isn't just a matter of engineering the protocol.  There are security
> > problems involved in making this happen (like: [...]
> 
> And that's a good reason for not engineering a specific hole in our protocols!

Or at least being very careful about it.

> > And anyways, operators already get to do this by simply forcing users to use
> > devices from the operators (modified to have MITM CA trust anchors).
> 
> Except, we really want to close that particular hole, don't we? I

Authorized MITMing is fundamentally a part of any hierarchical
distributed, public key authentication system when the user does not
have full control of their user agent.  We can detect it in some cases
when it's unwanted, but if it is "authorized" (by the "owner" of the
device) then it's going to happen.

All the more reason to ask why we're even discussing this.

> don't know which particular combination of caching, logs and third
> party referrals we will end up standardizing, but we have to assume
> that the security stack will eventually detect this kind of meddling,
> and expose it. At a minimum, this is going to be a significant PR
> issue for any telco playing that game.

Maybe.  I assume many operators are doing this now, so whatever PR
problems might result from starting to filter, they are in the past for
many operators.

Nico
--