Re: [saag] Ubiquitous Encryption: content filtering

Stephen Kent <kent@bbn.com> Mon, 22 June 2015 20:25 UTC

Return-Path: <kent@bbn.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 85FF01AD072 for <saag@ietfa.amsl.com>; Mon, 22 Jun 2015 13:25:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.511
X-Spam-Level:
X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 vU-nAK_UevqN for <saag@ietfa.amsl.com>; Mon, 22 Jun 2015 13:25:30 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5CD41AD06D for <saag@ietf.org>; Mon, 22 Jun 2015 13:25:29 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:53303 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1Z78HY-0005qz-Lf for saag@ietf.org; Mon, 22 Jun 2015 16:25:28 -0400
Message-ID: <55886F38.4030906@bbn.com>
Date: Mon, 22 Jun 2015 16:25:28 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: saag@ietf.org
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>
In-Reply-To: <55844743.4030300@cs.tcd.ie>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/GruXHc11-GmfgKG8Wua5z7qi6j0>
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 20:25:31 -0000

Stephen,

> ...
>
> So even if thing-X is required by some local regulator, that does not
> by itself mean that the IETF needs to care about thing-X.
>
> I'm sure this is familiar to many long time IETF participants, but it
> may well not be commonly understood by some others who would consider
> the argument Kevin makes above as a winning argument.
On purely technical grounds, an argument for filtering in the "middle"
is reasonable. It's much easier for a mobile operator, an ISP, or an 
enterprise
IT organization to perform content filtering at an intermediate point 
than to try t
o do so in every end point device. That's a major reason why enterprise 
IT folks
prefer perimeter firewalls over endpoint firewalls. It's very difficult and
expensive to manage (security) software on a large number of user devices,
and it's even worse when those devices are diverse (e.g., Windows vs. Mac
vs. Lunix or iOS vs. Android, vs. ...).

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.

Steve