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

From: Kyle Rose <[email-masked]>
Date: Sun, 24 Jul 2016 08:00:10 -0400

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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 25 Jul 2016 09:18:27 -0700

Small comment in-line.

On Sun, Jul 24, 2016 at 5:00 AM, Kyle Rose <[email-masked]> wrote:

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

> 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

> 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
> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud
>
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 25 Jul 2016 22:20:27 +0200

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 <[email-masked]>:
> 
> 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

---

From: Kyle Rose <[email-masked]>
Date: Wed, 27 Jul 2016 10:41:55 -0400

(Forgot to respond to all.)

> about field lengths sufficient for expressing a small number of signals to

I think part of my hesitation results from my inability to think of any way
to express this in a meaningful way in the charter. The draft charter says:

q( Endpoint verification of signaling integrity, careful design of minimal
data structures, and restrictive policies for registration of signals can
help to meet this goal. )

and refers to Mirja's use cases document, but provides no explicit guidance
around what "minimal" means in an absolute sense, not with respect to an
individual use case . And I'm not sure it can or should get any more
specific (it is a charter, after all, not a technical draft or protocol
proposal), which leads to a dilemma: by not being more explicitly limiting
about total information per packet, are we setting ourselves up for a
situation in which the WG subordinates privacy to other goals and produces
and successfully deploys something too expressive, some time after which
users and governments end up in a game of chicken (idiom: driving two cars
toward each other at high speed, with the first driver to veer off the
loser) when some government bets that access to content is worth more than
the end-to-end integrity protection mandated by PLUS, leading it to
hijacking a valid PLUS field without endpoint cooperation, essentially
telling users "If you want access, you need to turn off integrity
protection"? Seems far-fetched now, but it takes only a critical mass of
impairment before users are required to comply just to interoperate: it
doesn't even have to result from laws in one's own country.

Pretty sure this shouldn't be addressed in the charter as a specific number
of bits, but I think you'd resolve a lot of fears of abuse by somehow
constraining the field space and the number of fields per-packet. (The
amount of data implied by "In-Band Measurement" jumped out at me as
problematic, for example.) And yeah, I get that this directly implies
additional potential for ossification. There are a huge number of tradeoffs
here, and there's no way to know we've made the right ones until long after
the decision has been made, but can we look at the proposed use cases and
decide which need to coexist in a single packet, and which maybe expose too
much space?

The other side of this (what can PLUS do *for* privacy?) I'll address in my
response to Mirja.

Kyle

---

From: Kyle Rose <[email-masked]>
Date: Wed, 27 Jul 2016 10:48:27 -0400

On Mon, Jul 25, 2016 at 4:20 PM, Mirja Kühlewind <
[email-masked]> 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
see.

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

Kyle

---

From: Dave Dolson <[email-masked]>
Date: Wed, 27 Jul 2016 20:31:00 +0000

Kyle Rose said:
“…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…”

The ability to obscure source addresses opens a huge attack surface for DDoS attacks, since there is no way to implement BCP 38 (Network Ingress Filtering).

Furthermore, to my knowledge, DDoS attacks are most effectively scrubbed precisely by correlating inbound packets with outbound packets that are evidence the protected service desires to communicate with the sender.
(I suppose a scrubber could simply discard most source-obscured traffic.)

Privacy is one side of security, but the ability to resist attacks is another important aspect. As far as I know, no one has figured out how to mitigate DDoS attacks at the receiving end-point.

I’m hoping this group can at least agree that mitigating DDoS attacks is a legitimate role of devices in the network.

-Dave

From: Spud [mailto:[email-masked]] On Behalf Of Kyle Rose
Sent: Wednesday, July 27, 2016 10:48 AM
To: Mirja Kühlewind
Cc: [email-masked]
Subject: Re: [Spud] Thoughts on the privacy concerns expressed at the BoF

On Mon, Jul 25, 2016 at 4:20 PM, Mirja Kühlewind <[email-masked]<mailto:[email-masked]>> 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.

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 see.
"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.)

Kyle

---

From: Kyle Rose <[email-masked]>
Date: Wed, 27 Jul 2016 16:52:44 -0400

Funny you should mention that. :-)

When Aaron and I were talking about this earlier, we were basically
throwing ideas around. When we got to this one, I mentioned how it would
neuter BCP 38, but that DoS protection might be achievable via some other
mechanism on a hypothetical future internet (especially since source
address verification only helps with a subset of DoS attacks: the most
difficult kind to deal with are those that are indistinguishable from
legitimate traffic).

At any rate, mentioning obscuring source addresses was not intended as a
well-thought-out proposal to be drafted tomorrow and standardized next
year, only as the kind of thing that might be appealing to privacy
advocates, and possibly feasible on an internet that looks very different
from today's. Just because I can't figure out how to do something doesn't
mean it's impossible.

Kyle

On Wed, Jul 27, 2016 at 4:31 PM, Dave Dolson <[email-masked]> wrote:

> Kyle Rose said:
>
> “…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…”
>
>
>
> The ability to obscure source addresses opens a huge attack surface for
> DDoS attacks, since there is no way to implement BCP 38 (Network Ingress
> Filtering).
>
>
>
> Furthermore, to my knowledge, DDoS attacks are most effectively scrubbed
> precisely by correlating inbound packets with outbound packets that are
> evidence the protected service desires to communicate with the sender.
>
> Privacy is one side of security, but the ability to resist attacks is
> another important aspect. As far as I know, no one has figured out how to
> mitigate DDoS attacks at the receiving end-point.
>
>
>
> I’m hoping this group can at least agree that mitigating DDoS attacks is a
> legitimate role of devices in the network.
>
>
>
>
>
> -Dave
>
>
>
>
>
>
>
> *From:* Spud [mailto:[email-masked]] *On Behalf Of *Kyle Rose
> *Sent:* Wednesday, July 27, 2016 10:48 AM
> *To:* Mirja Kühlewind
> *Cc:* [email-masked]
> *Subject:* Re: [Spud] Thoughts on the privacy concerns expressed at the
> BoF
>
>
>