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

Kyle Rose <krose@krose.org> Sun, 24 July 2016 12:00 UTC

Return-Path: <krose@krose.org>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 17F7312B040 for <spud@ietfa.amsl.com>; Sun, 24 Jul 2016 05:00:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id padnet_wksUI for <spud@ietfa.amsl.com>; Sun, 24 Jul 2016 05:00:12 -0700 (PDT)
Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (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 A9C4D12B009 for <spud@ietf.org>; Sun, 24 Jul 2016 05:00:12 -0700 (PDT)
Received: by mail-qk0-x243.google.com with SMTP id q8so11972897qke.3 for <spud@ietf.org>; Sun, 24 Jul 2016 05:00:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=2FajbjQCIb0LhXEFTxa3NqlxzK0be2LaIDfzQubjdwU=; b=YL+JhHmSmGeDY6EI3ufW6KaFn/NGhh4wkdqrTqsJcTlXlai7LY77aIUC+Dpwg9Na0H 1lbxU3a5GecZb/DHjmNa4gVydW8q3seHMPK5g/5yMDgwBvXeAvdex31aUqYuTVMH67jU qbohXURDDv/DwGlcfz3LN44bfAQNQeY4IZ9P0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2FajbjQCIb0LhXEFTxa3NqlxzK0be2LaIDfzQubjdwU=; b=ZNV1pFqcPJAaaFIMRVN/n227MtnpvsOvlsmhU//KmI4LPYOU77xdwFYwMcXtYWyxD+ 6N0GrZOXEE9VRkr64mr4sui6FuaIMdWYNgFgD6jAXaXOvH37UYST0NM74otGAPlp5ZEw J2+E0IKOiszDfbAbsmC5g+tO4JsL9TEe96JbPoMdXSgQrohDFg/kKoKnqkHQDzj0cSDP 7ie334dEJwAYqfpjThfWDDNFkltkm6hng62dUKYhoU++DsOLZbuFU62PXGbw8Wn+S/zf wY52vs2/V1XVxL89zllPklJ09R/1BcDaCjGeTx4wRwXsn/2qQXV86sDM0+qv5loRopHp L54w==
X-Gm-Message-State: AEkoouuTYRC60kJl88YX7AkEu3vKjJkbBlPA7MFJw24xxpHZ3JZGJ12woZqeEFmZdhWhUgUtmqMNq9VLzdFc4w==
X-Received: by with SMTP id p39mr15686657qkp.119.1469361611489; Sun, 24 Jul 2016 05:00:11 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 24 Jul 2016 05:00:10 -0700 (PDT)
X-Originating-IP: [2001:470:1f07:121:6946:8c8e:426d:13ff]
From: Kyle Rose <krose@krose.org>
Date: Sun, 24 Jul 2016 08:00:10 -0400
Message-ID: <CAJU8_nUDZnYuN0RHHyw0CCoK47mdpJV2OkZTGVeNBa-0p1R0KA@mail.gmail.com>
To: spud@ietf.org
Content-Type: multipart/alternative; boundary=001a11493a04e658c705386068aa
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/6MTTSuNfMUFPEYVgxPCztnh0F68>
Subject: [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: Sun, 24 Jul 2016 12:00:15 -0000

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.

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.

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

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

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.