Re: [Spud] Thoughts on the privacy concerns expressed at the BoF

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Mon, 25 July 2016 20:20 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F41012D9EB for <spud@ietfa.amsl.com>; Mon, 25 Jul 2016 13:20:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Level:
X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 eBqj9Ntkr_ZB for <spud@ietfa.amsl.com>; Mon, 25 Jul 2016 13:20:30 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5525312D9EE for <spud@ietf.org>; Mon, 25 Jul 2016 13:20:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 94065D930E; Mon, 25 Jul 2016 22:20:28 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eEdBPeaa6+Zj; Mon, 25 Jul 2016 22:20:28 +0200 (MEST)
Received: from [192.168.178.33] (p5DEC2F62.dip0.t-ipconnect.de [93.236.47.98]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 33DC8D930D; Mon, 25 Jul 2016 22:20:28 +0200 (MEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: =?utf-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>
In-Reply-To: <CAJU8_nUDZnYuN0RHHyw0CCoK47mdpJV2OkZTGVeNBa-0p1R0KA@mail.gmail.com>
Date: Mon, 25 Jul 2016 22:20:27 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F6C0D9A5-1E2D-446D-A6E3-9AD148296631@tik.ee.ethz.ch>
References: <CAJU8_nUDZnYuN0RHHyw0CCoK47mdpJV2OkZTGVeNBa-0p1R0KA@mail.gmail.com>
To: Kyle Rose <krose@krose.org>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/as5Fqrv90uTJE8s2SbRwSHR7KZI>
Cc: spud@ietf.org
Subject: Re: [Spud] Thoughts on the privacy concerns expressed at the BoF
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2016 20:20:33 -0000

Hi Kyle,

thanks for bring up this discussion again on the list and stating your view point here. I think we really need some more discussion to come to a common view point on what is possible today, where the problems are, how we can improve today’s situation and how we can instruct current and future protocol development in the IETF to address these concern in a constructive manner. Please see further, more detailed comments below.
  
> Am 24.07.2016 um 14:00 schrieb Kyle Rose <krose@krose.org>rg>:
> 
> Following the BoF, I spoke with several folks who hummed "no" to the first question on privacy grounds. There were two main concerns I heard voiced: concrete issues with standardizing a mechanism for passing arbitrary metadata, and the more amorphous problem of the wise not being able to see all ends.
> 
> The concrete concerns are straightforward to understand, even for those who don't agree: at least from my perspective, dismissals of the form "But they (operators, governments, etc.) can already add arbitrary metadata!" fail to take into account that an internet standard for adding arbitrary metadata to client requests makes it much easier for governments and others to coerce users into adding identifying information to every packet and know that it will survive end-to-end, and interoperate universally, over the entire internet and not just within the source networks.

As mentioned by Ted, this is actually not what we propose. The mechanism we propose is exposing information under endpoint control which is a very important point here. The endpoint has to add an option to send (or request) a specific bit of information (which also must be registered by IANA with IESG approval). This is just the same as TCP options or IP option headers. The only difference is that PLUS has a MAC which allows detection of middlebox manipulation (which is not the case for other existing protocols such as TCP options). This is another a very big and important aspect of what we propose with PLUS as our goal is to encrypt everything above PLUS including the TCP header and TCP options in future. Especially encrypting TCP option is important because TCP options provide much less control than what we propose with PLUS today which is a problem (especially as currently still unto 90% of the traffic is TCP). So I actually though we are on the same page here and have a common goal. 

As you probably know from tcpinc discussions it is today not possible to just encrypt the whole TCP header because this will lead to huge deployment problem (and incentive people to actively block encryption), however, providing a replacement mechanism that actually gives the control really back to the endpoint and provides the needed (not privacy sensitive) information in the network is the goal here. (This also enables protocol innovation again because at this point the network does not need to know anymore which protocol is used, which makes it even more save). 

Of course this can be used to also add additional information that we don’t have today in the TCP header (however, we can also define new TCP options or IP headers or HTTP extension... and there are existing bad examples… or just use them with out an RFC or simply register an experimental TCP Option and use it forever and ship products with it... or... or... or…). However, the goals is to provide information which can actually be used make the network work better. Similar as some information that we are exposing today (such as port numbers and/or timestamps), the information we are looking for should in it self not be privacy sensitive and by using a new approach for exposing we can even take additional care now to make sure this information cannot be used in such a way (which is not the case for TCP timestamps today as the clock used might identify the client). Designing this now with a strong privacy awareness can also just improve the situation compared to what we have right now.

> 
> That means, for instance, not having to strip proprietary encapsulation at exchanges/peering points, or to build and maintain proprietary software and network hardware: this potentially creates a glide path to global user activity tracking, something I suspect most government officials would love to have. End-to-end survivability is a property that PLUS (probably?) needs if it is going to be useful, but is something we don't want for arbitrary extra-protocol metadata that may have nothing to do with traffic management or routing. A too-general mechanism is disqualifying on these grounds.

I’m not sure I understand this point fully because PLUS is an end-to-end protocol (this is why we discuss it in the transport area) and as today for all other traffic the packet length is limited by the path MTU. So adding additional data, that is not requested by the client, provides the same difficulties with the same solution that we have or may not have today. Only that PLUS makes any unwanted mangling detectable by the endpoint, which is usually not possible today.

> 
> To the second hum ("If scope were restricted to flow state semantics and multi-path, would that be agreeable?"), it's not clear to me how much of the objection comprised general resistance to giving any useful information to middle boxes to prevent ossification

Explicitly talking to middleboxes has two aspects: 1) Middleboxes do not need to makes assumption about what the end-point is doing based on random information that is visible, and 2) by providing these information the service the network provides can actually be improved. 

> , versus to concerns that even those limited semantics could still be used to invade users' privacy (versus other concerns).

None of the use cases we discuss in draft-kuehlewind-spud-use-cases propose that privacy sensitive data should be exposed. I think there are many good example where exposing information about traffic semantics and characteristic on a high level that is useful for the network, is possible and can help a lot, both the user experience and network management. 

We do understand from the BoF that the scope is not well enough defined yet (mostly from other comments not related to privacy thought) and we will work on this, probably by restricting the scope to an initially set of use cases that provide the most deployment incentives, such as NAT traversal and diagnosability.

> While I am concerned about further ossification of the protocol stack, the latter issue is more troubling to me because the privacy implications of even a few bits of metadata are still unclear in this early stage of recognition of the existence of pervasive surveillance.

This argument is for me so high level that I think it can be used to stop nearly all work in the IETF, at least all work in transport. 

As I said in the beginning, I think we need to get a common understanding here, and then work together on new protocols and mechanisms. Just blocking work from the beginning seems rather counter-productive to me.  

> We don't want to standardize something that turns out, for example, to be a side channel for identifying information when transmitted in large enough quantities. Mathematical/statistical guidance here would be particularly helpful.

Today this is possible. TCP timestamps is a simple example. TCP timestamps are an important tool for TCP, however, they are also used for in network measurements (as they are visible). Would we have given network operators a useful tool for measurements in the first place, they would not need to misuse TCP timestamps. Would we have thought about TCP timestamps in the first place such that they can not be used as an identifier, we would not have this problem already today. Let’s please fix this now!

> 
> All that having been said, on the other side are concerns that if we don't standardize something the demand won't simply disappear: like NAT, refusal to cough up an acceptable official standard doesn't mean that a worse de facto standard won't emerge. It's not entirely clear to me how analogous the two situations are, or how likely this outcome is, but it is a valid concern.

I really share this concern!

> 
> I am not firmly against PLUS, but I won't support any proposal that doesn't adequately address these issues. What I need is either a convincing argument that my privacy concerns are crap (however unlikely that seems now), or a protocol proposal narrowly-tailored enough that I'm convinced abuse won't be possible.

These privacy concerns are not crap but the situation today is already bad and we propose something that can actually improve the situation. I don’t think there is a perfect solution, especially as it hard to think about all bad ideas people might have in future. However, I don’t think it’s the right way forward to use these concerns to block needed work.

Mirja


> 
> Kyle
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud