Re: [saag] Ubiquitous Encryption: content filtering

Joseph Lorenzo Hall <joe@cdt.org> Fri, 19 June 2015 15:58 UTC

Return-Path: <jhall@cdt.org>
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 4FEBF1A9126 for <saag@ietfa.amsl.com>; Fri, 19 Jun 2015 08:58:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.199
X-Spam-Level:
X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 vZWtwgtNZLCU for <saag@ietfa.amsl.com>; Fri, 19 Jun 2015 08:58:19 -0700 (PDT)
Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542DF1A9120 for <saag@ietf.org>; Fri, 19 Jun 2015 08:58:19 -0700 (PDT)
Received: by laka10 with SMTP id a10so76931570lak.0 for <saag@ietf.org>; Fri, 19 Jun 2015 08:58:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=i/tMU45CRceEp21nmWmjLcf4dJ+Pb4bjFWcZTFtMKIM=; b=gPPuzUJ+R7NqFZXKbiZ2b5SxMNrge4595bMB99tdxmWZllQUC1MXTN/pa+aoLqkKbt a0g/uQbdt4e06mgUsUOWrrtB0Mpm5UYLVaLWiGdG8MjwDv4XjkiUdUI030LbLyQVw5kt gsRXECmwhJD1RiC1wA8Ubg2d5+iSX2o7Zw4IufsMQnU7VEh0gbOzCwuQkDAHsCqtZKqz wrz4P8squ/gPM/FZaLPhM2Me5lA4wVWWBlwkKbHv9DAsoKLRxQHaXp33ZFMPWjPPA3cw m3MtTLas6nSvVToa0nEe0C8EV7YC+E44nDXlCtSyqxfvBORRqxL/dPr32WhwZHY62Mp1 eDRQ==
X-Gm-Message-State: ALoCoQlqPNWG8UKQ0qSPBt9ExOHHWMXKDrkOcAjNqaFsix6zWW3aZIFaufrQFJl+2XWcZNAgEFez
X-Received: by 10.112.140.137 with SMTP id rg9mr18532163lbb.101.1434729497764; Fri, 19 Jun 2015 08:58:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.154.5 with HTTP; Fri, 19 Jun 2015 08:57:57 -0700 (PDT)
In-Reply-To: <A4BAAB326B17CE40B45830B745F70F108E070156@VOEXM17W.internal.vodafone.com>
References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> <CABtrr-U9kLfq4GQbWSgPN=wCD=Cdi0uQ+bQqXj35j+PFtuE8Pg@mail.gmail.com> <A4BAAB326B17CE40B45830B745F70F108E070156@VOEXM17W.internal.vodafone.com>
From: Joseph Lorenzo Hall <joe@cdt.org>
Date: Fri, 19 Jun 2015 11:57:57 -0400
Message-ID: <CABtrr-UbkXEXmO5Vz7ky9cVQGk-4rQTCO7NMoezESNje4SWhhw@mail.gmail.com>
To: "Smith, Kevin, (R&D) Vodafone Group" <Kevin.Smith@vodafone.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/mtsoYy4MY7wGAHykM1h__YY3B_0>
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 15:58:21 -0000

On Fri, Jun 19, 2015 at 10:07 AM, Smith, Kevin, (R&D) Vodafone Group
<Kevin.Smith@vodafone.com> wrote:
>
> > 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.

Text that expresses the intent you've described here I think would be
useful if Natasha's text is pulled in.

> > 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.

Totally understood. (workshop? or I-D?)

> 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




-- 
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