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

Kyle Rose <> Wed, 27 July 2016 14:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9F5112DAD0 for <>; Wed, 27 Jul 2016 07:48:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id loSwkcseD5tp for <>; Wed, 27 Jul 2016 07:48:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C5C7B12D85A for <>; Wed, 27 Jul 2016 07:48:28 -0700 (PDT)
Received: by with SMTP id s63so36183698qkb.2 for <>; Wed, 27 Jul 2016 07:48:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eevFpP3gE2qFBVyyA1i0VZ8M/h2G/lopzmzC56oC/6s=; b=X0EDlWx3G8gghWc6rQv0lhp455fKfOzkz+CQtlhRSIQq4cQFjOL8JHiSLgNFI6cBnf +XnO024fbM8UARdUJ09rs82K+Q7KzbOzRBT7IvQ+ww9Xt5VBUrTjgooDmsQbc/OKYF13 CYtJC2qJ8PY+eCNPPEx5v69qX8sD1chKj/0Io=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eevFpP3gE2qFBVyyA1i0VZ8M/h2G/lopzmzC56oC/6s=; b=Kb3L1XtUYAB8uxPeohXBm78w9AhumkgbI2nFPJP2S+IIxdjZfFrrcbKAQM4UQT26ZW ORlSxKfRe/kThqLRtKMykK/8hHBf3E2qnG/rtrCLG5oF/3xNRXiB5ZMDxEnOFDQe1jH9 MFrO7hKyqXLhhge2FKnd1sT4fEo2mnHEh1ykvS/bzzvsLzRWkEDyA/2O9tak3SHtNSKz 94umz/ICVWz+vjtMf715SkpKUH8NLvxIBN41BstUsIrJmnBV8iQsziO3zmTVh1Z6I59M vwt5lFOOstBFGTREHH4InQauIY4yT0zGTsxM1y58xXynNGrVjwjfZ4+LoHwNMGmscGWs tR8A==
X-Gm-Message-State: AEkoouv9qyRVR4YrXSWlxyPTYI2hYsHMG/UhFqEHwTuw1U2zvez896Xz8Iq5u2NGk7jDtDBK1Pws8axFX52vCg==
X-Received: by with SMTP id t22mr35501301qka.171.1469630907888; Wed, 27 Jul 2016 07:48:27 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 27 Jul 2016 07:48:27 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <>
From: Kyle Rose <>
Date: Wed, 27 Jul 2016 10:48:27 -0400
Message-ID: <>
To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= <>
Content-Type: multipart/alternative; boundary=001a114ab99c3764ec05389f1c9f
Archived-At: <>
Subject: Re: [Spud] Thoughts on the privacy concerns expressed at the BoF
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Jul 2016 14:48:37 -0000

On Mon, Jul 25, 2016 at 4:20 PM, Mirja Kühlewind <> wrote:

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

I totally buy the positives here, and I think maybe more language pitching
and justifying this as at-worst an even trade of privacy concerns by
removing some existing, completely-unprotected covert/side channels and
replacing them with only exactly what the path needs to know (humbly, from
our always limited technical perspective) in order to manage flows in a
world in which the entire internet is running over UDP is part of what is
missing from the proposed charter.

I had a long talk about my post with Aaron Falk on Monday, and as a result
of that conversation I became hopeful that much more information about data
flows could be obscured in a PLUS-enabled internet than is possible today,
perhaps even to the point of obscuring source addresses and making flows
and maybe even individual packets to busy endpoints hard to correlate
without tap points at every router on the internet doing collective traffic
analysis. That's a long way off, but that is a future many would like to

"We don't think this has any additional privacy impact" is a much weaker
statement than "This can be the foundation for much greater privacy of
metadata, not just of payload", and is more prone to FUD because it puts
you on a defensive footing against many possible (and vague) lines of
attack, and the burden of proof is always on those proposing changes.
Thinking ahead to what we want the internet to look like in 20 years is a
prerequisite to making sure that what we're doing lays just enough
groundwork to make that possible, and is something that I think many
privacy advocates could get on board with.

(I do also want to add that I recognize a bit of cognitive dissonance in
myself, as I've repeatedly expressed skepticism about adding real privacy
at the routing layers on the public internet, versus private networks on
top of that, like TOR. That said, the antecedents of that skepticism may
not be true in a 2036 internet, so systematically strengthening the
desirable properties of the internet's foundations is likely not to be
wasted work, as long as we have a reasonable idea of where we're headed.)