Re: [saag] Ubiquitous Encryption: content filtering

"Smith, Kevin, (R&D) Vodafone Group" <Kevin.Smith@vodafone.com> Fri, 19 June 2015 14:08 UTC

Return-Path: <Kevin.Smith@vodafone.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 3BE341A0318 for <saag@ietfa.amsl.com>; Fri, 19 Jun 2015 07:08:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 6s2ZO6IEeTIJ for <saag@ietfa.amsl.com>; Fri, 19 Jun 2015 07:08:03 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FEDC1A02BE for <saag@ietf.org>; Fri, 19 Jun 2015 07:08:03 -0700 (PDT)
Received: from [85.158.139.163] by server-6.bemta-5.messagelabs.com id 2C/C6-08467-D3224855; Fri, 19 Jun 2015 14:07:57 +0000
X-Env-Sender: Kevin.Smith@vodafone.com
X-Msg-Ref: server-14.tower-188.messagelabs.com!1434722875!10473151!1
X-Originating-IP: [195.232.244.136]
X-StarScan-Received:
X-StarScan-Version: 6.13.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9858 invoked from network); 19 Jun 2015 14:07:56 -0000
Received: from mailout04.vodafone.com (HELO mailout04.vodafone.com) (195.232.244.136) by server-14.tower-188.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Jun 2015 14:07:56 -0000
Received: from mailint03.vodafone.com (mailint03.vodafone.com [195.232.244.200]) by mailout04.vodafone.com (Postfix) with ESMTP id 3mChmW4JK9znTYP; Fri, 19 Jun 2015 16:07:55 +0200 (CEST)
Received: from mailint03.vodafone.com (localhost [127.0.0.1]) by mailint03.vodafone.com (Postfix) with ESMTP id 3mChmW38c8z16J6k; Fri, 19 Jun 2015 16:07:55 +0200 (CEST)
Received: from VOEXC06W.internal.vodafone.com (voexc06w.dc-ratingen.de [145.230.101.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint03.vodafone.com (Postfix) with ESMTPS id 3mChmW33W0z16LTY; Fri, 19 Jun 2015 16:07:55 +0200 (CEST)
Received: from VOEXC16W.internal.vodafone.com (145.230.101.18) by VOEXC06W.internal.vodafone.com (145.230.101.26) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 19 Jun 2015 16:07:55 +0200
Received: from VOEXM17W.internal.vodafone.com ([169.254.1.186]) by voexc16w.internal.vodafone.com ([145.230.101.18]) with mapi id 14.03.0224.002; Fri, 19 Jun 2015 16:07:54 +0200
From: "Smith, Kevin, (R&D) Vodafone Group" <Kevin.Smith@vodafone.com>
To: Joseph Lorenzo Hall <joe@cdt.org>, Natasha Rooney <nrooney@gsma.com>
Thread-Topic: [saag] Ubiquitous Encryption: content filtering
Thread-Index: AQHQqZyDVZfM/qjQ1ki7JjpGF/YhdJ2zrcSAgAAotYA=
Date: Fri, 19 Jun 2015 14:07:53 +0000
Message-ID: <A4BAAB326B17CE40B45830B745F70F108E070156@VOEXM17W.internal.vodafone.com>
References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> <CABtrr-U9kLfq4GQbWSgPN=wCD=Cdi0uQ+bQqXj35j+PFtuE8Pg@mail.gmail.com>
In-Reply-To: <CABtrr-U9kLfq4GQbWSgPN=wCD=Cdi0uQ+bQqXj35j+PFtuE8Pg@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/LsA6C9Un9_kDF7iULULCnHWLYPE>
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: <http://www.ietf.org/mail-archive/web/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: Fri, 19 Jun 2015 14:08:06 -0000

> I would at least like this to acknowledge that it's possible to do filtering at the endpoint. As you can imagine, I would argue another term for content filtering is censorship. best, Joe

Hi Joe,

Indeed, it is possible to filter at the endpoint. However, a mobile operator utilising licenced spectrum must adhere to regulations set by the government licensor, which include content filtering, or risk fines/licence suspension. The rise in end-to-end encryption may well change this situation; as if the regulators cannot constrain access via the operator network, it is likely they will look to other means. I'm in discussion with our legal and regulatory teams and aim to present on this at the workshop.

> As you can imagine, I would argue another term for content filtering is censorship.

Fair point, but we should focus on the technical options (e.g. endpoint vs. network filters) for the scope of this workshop. 

All best
Kevin

Kevin Smith, Vodafone R&D

-----Original Message-----
From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Joseph Lorenzo Hall
Sent: 19 June 2015 14:10
To: Natasha Rooney
Cc: saag@ietf.org
Subject: Re: [saag] Ubiquitous Encryption: content filtering

I would at least like this to acknowledge that it's possible to do filtering at the endpoint. As you can imagine, I would argue another term for content filtering is censorship. best, Joe

On Thu, Jun 18, 2015 at 3:58 AM, Natasha Rooney <nrooney@gsma.com> wrote:
> Hi all,
>
> I have a new submission for the Ubiquitous Encryption draft. I must 
> admit, this one is a little controversial, and certainly is not 
> something I believe in. However, I had a good think about it, and 
> figured that this is an "effect" of ubiquitous encryption, and maybe 
> would be beneficial for the draft. I am not expecting anything comes 
> out of adding it past education for members of the IETF community that 
> this is an issue for some organisations, governments and maybe users. 
> Please feel free to tweet me if you want to discuss personal views! Anyway, here we go:
>
>
> 2.3.X Content Filtering
> Law agencies may request Service Providers to block access to 
> particular sites such as online betting and gambling, sites promoting 
> anorexia, or access to dating sites. Content filtering in the mobile 
> network usually occurs in the core network. A proxy is installed which 
> analyses the transport metadata of the content users are viewing and 
> either filters content based on a blacklist of sites or based on the 
> user’s pre-defined profile (e.g. for age sensitive content). Although 
> filtering can be done by many methods one common method occurs when a 
> DNS lookup reveals a URL which appears on a government or recognised 
> block-list. The subsequent requests to that domain will be re-routed 
> to a proxy which checks whether the full url matches a blocked url on 
> the list, and will return a 404 if a match is found. All other requests should complete.
>
> Even in encrypted connections transport and lower layer metadata is 
> able to be viewed so for many systems content filtering should be able to continue.
> Cases when they may not work is when TLS proxies are being used which 
> obscure metadata with the proxy metadata, and future versions in HTTP 
> and TCP may encrypt metadata again stopping content filtering software 
> from working (this is currently not the case and has not been standardised).
>
> Some sites involve a mixture of universal and age-sensitive content 
> and filtering software in these cases may use more granular 
> (application layer) metadata to analyse and block; this will not work on encrypted content.
>
>
> I do have a few questions about what I have written, maybe someone can
> answer:
> [1] Does HTTP2 multiplexing do anything to content filtering software, i.e.
> when sending multiple requests for one webpage (loading images in 
> particular). I don’t think it does it’s just that my brain isn’t 
> working this afternoon...
> [2] Is it fair to mention future versions of HTTP and TCP when nothing 
> has been standardised yet? I don’t think so in which case maybe this 
> should be removed.
>
> Hope this didn’t ruin everyones morning! Thanks!
>
> Natasha
>
>
> Natasha Rooney | Web Technologist | GSMA | nrooney@gsma.com | +44 (0) 
> 7730
> 219 765 | @thisNatasha | Skype: nrooney@gsm.org Tokyo, Japan
>
>
> This email and its attachments are intended for the above named only 
> and may be confidential. If they have come to you in error you must 
> take no action based on them, nor must you copy or show them to 
> anyone; please reply to this email or call +44 207 356 0600 and highlight the error.
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>



--
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
joe@cdt.org
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag