Re: [Spud] Whats missing in SPUD

[Toerless Eckert <[e-mail]>]

On Mon, Aug 10, 2015 at 07:18:15PM -0400, Daniel Kahn Gillmor wrote:
> 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?

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.

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

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 ?

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

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