Re: [saag] Ubiquitous Encryption: content filtering

Nico Williams <nico@cryptonector.com> Mon, 22 June 2015 21:12 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 4D1581A8754 for <saag@ietfa.amsl.com>; Mon, 22 Jun 2015 14:12:12 -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 THzbtuIfvXSD for <saag@ietfa.amsl.com>; Mon, 22 Jun 2015 14:12:11 -0700 (PDT)
Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 356B21A1B49 for <saag@ietf.org>; Mon, 22 Jun 2015 14:12:11 -0700 (PDT)
Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id C20A75940A5; Mon, 22 Jun 2015 14:12:10 -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=gPTZd71F3sl/By RAZxOiuuvCRjo=; b=YYa+A973yRnSPWc6jlS6PCsiYtUXfc0TiJNx9Y1RX8FiGa 4PkrzgaJU/Uz0fTkeWHOd1kIfu0PxIXCX6rrqxQBChnYOkZFrhInKi9US71t3IC1 wNwBzJHPDYHZgxnelKa6VFPTJOCgQbLcU3iCMoDbhlnwXtCqCLoXdSJTLgPSs=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPA id F211559409E; Mon, 22 Jun 2015 14:12:09 -0700 (PDT)
Date: Mon, 22 Jun 2015 16:12:08 -0500
From: Nico Williams <nico@cryptonector.com>
To: Stephen Kent <kent@bbn.com>
Message-ID: <20150622211207.GM6117@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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <55886F38.4030906@bbn.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/-xikfCuWeXNC1EwwI-0vGbgpXAk>
Cc: 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:12:12 -0000

On Mon, Jun 22, 2015 at 04:25:28PM -0400, Stephen Kent wrote:
> On purely technical grounds, an argument for filtering in the "middle"
> is reasonable. It's much easier for a mobile operator, [...]
> 
> So, from an engineering perspective, the argument about the conflict
> between end-to-end encryption and operator (including enterprise IT
> staff) access to traffic is a valid consideration, irrespective of the
> telecom-regulator argument.

But it isn't just a matter of engineering the protocol.  There are
security problems involved in making this happen (like: how do you
express to the user that there is one (or more!) middle box filtering
and/or modifying their traffic?  how do users get to opt out?  how is
scope limited?  (e.g., how do you prevent the device/operator from
MITMing the user when the user is NOT using the operator's network?)).

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).
What new technology is being requested here, regardless of whether
we'd publish it (though the current position as to that is clear: no;
but the IETF consensus can always change)?

Nico
--