Re: [saag] Ubiquitous Encryption: content filtering

Ted Hardie <ted.ietf@gmail.com> Mon, 22 June 2015 22:13 UTC

Return-Path: <ted.ietf@gmail.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 6015B1B29D5 for <saag@ietfa.amsl.com>; Mon, 22 Jun 2015 15:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 Ju3bpUPEhAyW for <saag@ietfa.amsl.com>; Mon, 22 Jun 2015 15:13:38 -0700 (PDT)
Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (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 0EA7B1B29D1 for <saag@ietf.org>; Mon, 22 Jun 2015 15:13:37 -0700 (PDT)
Received: by wgck11 with SMTP id k11so25688993wgc.0 for <saag@ietf.org>; Mon, 22 Jun 2015 15:13:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4fYArviHOypYJbcFNCnzmHiH3AGmwQBd/Wlnow5k834=; b=F99qUYK0ufWYj92VYqiJa4GD9mHQxZnd6oJYUywgbwwLrBW5xEhY2qF6QiSN9cT5oo lNahE/eZr0d4WQ+StXAD+QgmoKBFWgExqre7d/zVPgdaE6A3fMI6K5zWCRXrruYodwEI PsUkqpL9d9okw5FR5sOxoWdQZdafutcBWNxrx643i137ry7v3b/x7VeRrlVPue+yHJkF 0NGYyoMqNURCrokPxAnJgFN4xNclrCY6l40ps12VYB6LIEg2XfsyYo4hTapUCftglnWG /fmxLgPx9x1HjL4ZQJj9NZwy7mdvvfU7eqjugu4GZ4GbxRQz0eQ6sdiJTDWB93bpRCBh LNGw==
MIME-Version: 1.0
X-Received: by 10.180.9.111 with SMTP id y15mr35743286wia.18.1435011216657; Mon, 22 Jun 2015 15:13:36 -0700 (PDT)
Received: by 10.194.25.74 with HTTP; Mon, 22 Jun 2015 15:13:36 -0700 (PDT)
In-Reply-To: <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> <20150622214650.GN6117@localhost>
Date: Mon, 22 Jun 2015 15:13:36 -0700
Message-ID: <CA+9kkMBqV2aYXLTvA-5Ekd9S5Fqu0JdLTy3ZAdXVfD=X5KZ84A@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary="001a11c24888d1546305192295cb"
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/cMws996vpb-bkUpw7gLalfOMqGQ>
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 22:13:40 -0000

On Mon, Jun 22, 2015 at 2:46 PM, Nico Williams <nico@cryptonector.com>
wrote:

> On Mon, Jun 22, 2015 at 09:24:04PM +0000, Christian Huitema wrote:
> >
> 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.
>
>
​I'm a little confused by the quotes around both authorized and owner in
the statement above.  If a user has caused her device to use a proxy for a
specific protocol by configuration, that user has authorized that proxy's
activities.  If the user has instead initiated flows with the expectation
that they are going to the named service, rather than a proxy, then any
monkey in the middle is not authorized by the user.

Those activities are taking place to further the interests of other
parties.  For interception devices in a wireless network, those interests
might include inspection of the traffic type so that QoS may be assigned;
transcoding; content deletion; content insertion; and so on.

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.
>
>
​As others have mentioned, things change when you shift from intercepting
unencrypted channels to intercepting encrypted ones, as you are making a
much larger effort to impersonate the service.  That may be a difference of
degree, but it looks like a difference in kind.​

​regards,

Ted​




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