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

Ted Hardie <> Mon, 25 July 2016 16:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E23512B04D for <>; Mon, 25 Jul 2016 09:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qz9D6a3Gkmjq for <>; Mon, 25 Jul 2016 09:18:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 114D712D0E6 for <>; Mon, 25 Jul 2016 09:18:58 -0700 (PDT)
Received: by with SMTP id l72so259335653oig.2 for <>; Mon, 25 Jul 2016 09:18:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ve7Y9p+1RiUnP5AMOWlYZJtl8YDeLLeghNV+B7Ii28g=; b=qbXSWAftJ+BwE85FOE2UHbWsvA5+q9zUvvQEy/Wlc5ApiH8/4b+6s/eq0OkKgttvjP NcUXinW3Sl8EGNMzyuUgABj2BDIyL18Qs1fgY5ufX627hSoWI4AXxz6na3FwWWqlkrLw D2t0OCv7rJ/7hENrx7E9x8VVi9BfjktHaaaig7etJ9vAaD8uU8rROuoG1tXTNxE7jfa8 hKv/RXtPRRBZrPEshGlPVja+2qm4YPJYr+ByGC38HD9hH/+nBspXZOF3iz8oJzFLKiK3 KS7lIHVvdcGFgce5CB4ssccEYQYK3P9TL1z63Kl+t13vQnZqnMfUuqFtEXbkQRf+u/xq eVUQ==
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=Ve7Y9p+1RiUnP5AMOWlYZJtl8YDeLLeghNV+B7Ii28g=; b=T6UcEJOb3BYTMzclsHWuO8NGJZvsblxW6pBywpG1KAajNtsd/Ss9/x3QoaaZqwk6tS LpC+GBcHT9a8zO9bh/Xd/RvCNJjqT9EmoTLqA9d1nyEhQ2k+yIIUYSsFtY7xXpha8xCJ hkJ+uTiJ/2swpAxp/TUF9kPR0ytFfcLYsrV0bC4mlpTAiINX+RF7QfQo0rsIfRXxVZNw 6pJpo2VMbiOCcvknbAK2Re2BEcORisLvvKF67AKIjAIdx08bIZlEB1XKbPILhrqcEXF6 fxJkqmXcFCTVeVbipF0Ms9yNl1Bg8mozSgHVMl34SQ1Q1mcCYJdqKg3bOl1fict42H6I RPag==
X-Gm-Message-State: AEkooutgycTRVZ9a6CH0c0kiA3KttQPPXwpK94//H991CGjEaKSweXjmAObQzDo/725dsoRdEn6O1AWd+L3hwg==
X-Received: by with SMTP id i65mr8703235oia.61.1469463537264; Mon, 25 Jul 2016 09:18:57 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 25 Jul 2016 09:18:27 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Ted Hardie <>
Date: Mon, 25 Jul 2016 09:18:27 -0700
Message-ID: <>
To: Kyle Rose <>
Content-Type: multipart/alternative; boundary=001a113cf36a2650150538782492
Archived-At: <>
Cc: "" <>
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: Mon, 25 Jul 2016 16:19:00 -0000

Small comment in-line.

On Sun, Jul 24, 2016 at 5:00 AM, Kyle Rose <> wrote:

> 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

The intent, at least of the proponents, was never to allow for arbitrary
metadata.  As Brian and Mirja mentioned in the BoF, the intent was to limit
the values to those in an IANA registry, and to require standardization of
values added to the registry.  Of course, the IETF has no regulatory power
and no protocol police, so there remains a risk; previous attempts to use
IANA for enforcement have not all ended well.

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

Again, as Brian pointed out, we are not talking about field lengths here
that could serve this identifying function by themselves  we are talking
about field lengths sufficient for expressing a small number of signals to
the path.

> 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 am not so sure that government officials want to have a system in which
insertion is under the control of the end systems, which this proposes.
Transparency to the end systems is one of the properties we are trying to
achieve.  It may not be enough, of course, but it should be noted.



> 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, versus to concerns that even those
> limited semantics could still be used to invade users' privacy (versus
> other concerns). 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.
> 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.
> 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 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.
> Kyle
> _______________________________________________
> Spud mailing list