Subject: [Spud] Whats missing in SPUD (was: Re: Multipath/Mobility (was Questions based on draft-trammell-spud-req-00))

From: Toerless Eckert <[email-masked]>
Date: Mon, 10 Aug 2015 11:44:44 -0700

[another resend due to spud mailin list setup, sorry]

As a generic side thought based on Christians concern about privacy
(why would an app want to show a shared Tube-ID across multipath/mobile flows for example).

To me, the problem is best explained on the following workflow:

"Here is your new ID card".
"Why would i want to have an ID card, everybody who checks ID cards is evil"
"You do not have to show your ID card if you don't want to"
"Lets go to the bar"
"ID card please"
"Booze or anonymity... that's the question"
"Lets choose booze"

So, whats missing in SPUD (or any prior endpoint<->network) signaling is the
signaling element "If you do not show ID card, you will not get booze" or
"if you do not use a cross-subflow Tube-ID, your load-sharing, mobility or multipath
performance will suck or not work".

Using the same Tube-ID is just one example. This interaction really applies
to any possible signaling element: The anonymity freak will argue to his
death that he doesn't want to provide information to the network... unless
the network can persuade him that the benefit of showing outweights the
loss of anonymity. 

This is primarily a question of creating a data-model of what the network can offer
and tie that to a data model for what to show to get it....

Cheers
    Toerless

-- 
---
Toerless Eckert, [email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Mon, 10 Aug 2015 20:20:19 +0000

On Monday, August 10, 2015 11:45 AM, Toerless Eckert wrote:
> As a generic side thought based on Christians concern about privacy (why would
> an app want to show a shared Tube-ID across multipath/mobile flows for
> example).
> 
> signaling element "If you do not show ID card, you will not get booze" or "if you
> do not use a cross-subflow Tube-ID, your load-sharing, mobility or multipath

That's exactly the kind of choice that I would not like the application to make. Take multipath as an example. The application can do it in two ways. It can use the same "tube ID" on both paths. Or, it can use two different IDs, and reassemble the packets in the end system. There are pros and cons in both architectures. 

If the application uses a single ID, the load balancers in front of the server farm can easily assign packets to the right context. If the application uses two identifiers, the servers need to somehow communicate to the load balancers that the two IDs should really map to the same context. That's more complex, but that's the main drawback of using two different IDs.

The other potential drawback of using two IDs is that the on-path elements cannot manage a single set of allocations for the two paths. But then, if the application is actively trying to use two different paths, it probably does not want those two paths to be managed as one, as that would defeat the purpose of multipath.

On the other hand, if the application uses the same ID, it discloses that two different IP addresses really belong to the same device, which is a great way to enable tracking. In the common case of cellular + Wi-Fi, this enable tying the Wi-Fi usage, typically randomized and anonymous, to the cellular usage, which is typically "managed." Note that applications doing that do not just put their own traffic at risk. By "leaking metadata," they are effectively breaking the privacy of other applications as well.

-- Christian Huitema

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 10 Aug 2015 16:32:37 -0400

> "Booze or anonymity... that's the question"

Have you ever tried to go to a bar where they require you to scan your
full ID into their targeted advertising database in order to step inside
for a pint with a friend? [0] They say they're asking this information
for the purpose of avoiding alcohol service to underage people.

The full ID scan (at least where i live) contains legal name, home
address, biostats (height, weight, hair, eye color), date of birth,
license number, physical impairments, etc.  The bar says "we need to
know whether you can legally drink" (a boolean value) and instead
collects a timestamped, identity-mapped, rich-characteristic profile of
every individual who enters the establishment.

You're right, of course, that most people in such a situation will
choose booze over their own privacy.  i won't go into the number of
reasons that people feel compelled to make this choice unless i get a
signal from the chairs that this kind of behavioral analysis is on-topic
for the list.

But the fact that many people are willing to make this tradeoff is not a
legitimate excuse to design a system that encourages the tradeoff to be
made this way.

That exchange is fundamentally a bad deal for the user, even if we
accept as a given that a bar needs an automated mechanism that allows it
to distinguish legal drinkers from underage drinkers. Users shouldn't be
forced into trading off privacy for network access any more than they
should be forced into trading off privacy for security [1], and we
shouldn't design mechanisms to encourage this false trade.

> So, whats missing in SPUD (or any prior endpoint<->network) signaling
> is the signaling element "If you do not show ID card, you will not get
> booze" or "if you do not use a cross-subflow Tube-ID, your
> load-sharing, mobility or multipath performance will suck or not
> work".

This is *exactly* what i'm concerned about with SPUD.  Full user
identification is overkill for detection of who is allowed to drink (or
who is allowed to use the global network); it is a disaster for user
privacy, and a total bonanza for a would-be pervasive monitor.

We're suposed to be pushing back on that kind of thing, right?

  https://tools.ietf.org/html/rfc7258
  https://tools.ietf.org/html/rfc6973

Formalizing this practice would put any network operator in the position
of the overzealous bar-operator/marketer: "give me your ID card via SPUD
to be able to send or receive traffic", not to mention criminals looking
for a home address to burgle based on who's out at the local cafe,
nation-states looking to repress their own citizenry, or spy agencies
fetishizing the need to "collect it all".

> Using the same Tube-ID is just one example. This interaction really
> applies to any possible signaling element: The anonymity freak will
> argue to his death that he doesn't want to provide information to the
> network... unless the network can persuade him that the benefit of
> showing outweights the loss of anonymity.

We should not be designing protocols that encourage users to give up any
amount of anonymity to the network without compelling engineering
argument (and evidence!) that the anonymity they give up is necessary to
the effective operation of the network.

Otherwise, we're building a network that is designed to encourage its
users to accept this fundamentally bad deal in a place that is today far
more critical to civic interaction than a bar.

I will accept the label of "anonymity freak" if it means i am concerned
about the social impact of a thoroughly-surveilled society.

Thanks for the good example.

Regards,

    --dkg

[0] fwiw, i have been to a bar that has this requirement.  I have not
    returned to that bar.

[1] https://www.schneier.com/blog/archives/2008/01/security_vs_pri.html

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 10 Aug 2015 14:06:18 -0700

Well, biostats/signature/photo  constitute elements to establish ownership
of the ID card. And there may be county/city police regulations to keep
track of full ID scans. And if not police then insurance or on advice
of the bars lawyer in case of lawsuits/challenges. Aka: IMHO much more likely
caused by third party directives then lets say the customer data collection
done by eg: web/social-networking sites.

But lets agree that the ID card in its current form is not ideal to
exemplify "know what attributes you need to show for the desired benefits
and then only show those attributes".

So the right example would have been some form of ID card with keypad,
i type in what attributes i want to send, it creates a new short lived cert
and NFC's those attributes to the gatekeeper. Whether its Photo + (Age > 17) or anything else.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 10 Aug 2015 19:18:15 -0400

On Mon 2015-08-10 17:06:18 -0400, Toerless Eckert wrote:
> Well, biostats/signature/photo constitute elements to establish
> ownership of the ID card. And there may be county/city police
> regulations to keep track of full ID scans. And if not police then
> insurance or on advice of the bars lawyer in case of
> lawsuits/challenges. Aka: IMHO much more likely caused by third party
> directives then lets say the customer data collection done by eg:
> web/social-networking sites.

Sure.  So should we design a protocol that facilitates the publication
and collection of arbitrary data that might be of interest to any
regulator/lawyer/advertiser/insurer (or criminal/spy/competitor/troll)
able to influence any device along the path?

I share your concern about the customer data collection done by
web/social-networking sites, which today are indistinguishable from "the
network" for many users.  But the remedy for this is not to help make
the lower layers of the network (i.e. IETF purview) as bad for user
privacy as the worst of the centralized services are.

> and then only show those attributes".

That's why we're having this discussion -- because we do not want to
produce a network transport protocol with sufficient flexibility and
power to implement the "show your full identity to an arbitrary
intermediary order to be able to socialize" antipattern, even though i'm
sure some arbitrary intermediaries would love such a thing.

> i type in what attributes i want to send, it creates a new short lived
> cert and NFC's those attributes to the gatekeeper. Whether its Photo +
> (Age > 17) or anything else.

We're not designing a beer-delivery protocol layer (though that does
sound like more fun), we're designing a network transport layer.  It
should be designed for transporting data through the network, not for
facilitation of arbitrary interference by any network operator.

Can you reframe your proposal in the network transport layer context in
a way that seems feasible to implement, is comprehensible to the user,
doesn't encourage the false-tradeoff antipattern, and is actually
effective at improving user experience on the network (as compared to,
say, spending the same amount of engineering effort on a faster link
layer)?

All the best,

        --dkg

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 11 Aug 2015 00:09:59 -0700

> able to influence any device along the path?

How do you prohibit in the design of html that a browser and server
exchange arbitrary data in the html header ?  In the end, SPUD attributes
network->app and vice versa are to me really very similar.

IMHO we do need to separate the design of the SPUD communication patterns
from the semantics of the individual attributes, otherwise we never get
to a useful and flexible, extensible protocol.

> sure some arbitrary intermediaries would love such a thing.

Lets say you don't trust your browser. What makes you confident the browser
can not exchange that undesired data through any other protocol ? Do
you trust a browser with IDS/firewall/etc to prohibit a browser from
doing something malicious against you ?  If you do trust the browser
(not app on top!) then i think its easy for the browser to only exchange
data that we like.

Aka: Lets discuss not only the protocol, but the overall system expectation
including your app. SPUD implement natively in browser (browser can
build appropriate barrier towards app to control what can be
sent/received via SPUD. That already makes the system better than
most other app-channels). You do have your login credentials for your
bank in your keystore acessible to the browser. Do you trust the browser
to not use an arbitrary protocol to send out that key data in the clear
to anybody in the world. SPUD or any other protocol ?

> say, spending the same amount of engineering effort on a faster link

To characterize the app/flow behavior/expectations we did discuss over
the years many attributes. I am not sure there is a lot of agreement
on which of these are most urgent ones. In ine implementation in Cisco
products we had about 20 attributes and thought of 20 more. But it was
mostly about QoS and thats very much evolving due to AQM, bufferbloat,
rmcat or the like, so i primarily want to havethe ability to define
attributes in the future if i am not sure what good long term relevant ones
are in this bucket.

An example QoS attribute is RTP clockrate of sRTP flows. Lets assume we do like that
the RTP header itself is in the clear, and we do expect our enterprise/SP
to monitor jitter/delay/loss/reorder to identify and monitor/account
and fix quality issues. Especially when it is over the top video whee the
SP must not have the sRTP keys because i stream from notflix.

When it comes to characterizing middlebox behavior towards the applications,
that much less well explored IMHO, look for the malice draft.

The more interesting side is attributes not for "QoS middleboxes", but
"security middleboxes". IMHO, those would for example like some secure app
identification:

For example they would use offpath solutions like identifying the app type
of the server endpoint IP of a connection via secure DNS or other means and
then classifying based on that server side IP. But lets assume there are also
p2p apps, like RTCweb media shortcuts or cloud storage with torrent technologies
so that you can't rely on the server IP for all their flows. Or you really can
only trust that the app does not leak confidential information when you
cryptographically can trust the client side too. Because the trusted client
does force all type of content checks on the user before sending a file
to the cloud. 

With todays HTTPs (if i am not mistaken), you (middlebox) could see
(via DPI) what cert the client side announces for itself.  I am not sure
if you could actually vet ownership as a middlebox, but if the app
was explicitly sending in SPUD its cert (or hash thereof) and then
signs something like the flow key and time, then this would constitute
a good secure client-app-id signaled in SPUD. Just as a starting
point idea. There are a lot other aspect in these type of crypto
security use-cases for signaling IMHO (limit if/when you want to 
identify yourself, identifying that you're inside a security perimeter
because of the middlebox identifying itself, aka: as soon as you're
talking cryto security use cases it always get a lot more complex
than you'd like ;-).

Cheers
    Toerless