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

[Ted Hardie <[e-mail]>]

Small comment in-line.

On Sun, Jul 24, 2016 at 5:00 AM, Kyle Rose <[e-mail]> 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.

regards,

Ted



> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud
>
>