Re: [Spud] SPUD Scope?

[Daniel Kahn Gillmor <[e-mail]>]

On Thu 2015-06-04 12:28:34 -0400, Szilveszter Nadas wrote:

> The rage looked like this to me on a high level:
>
> a) only start/stop, hide everything in DTLS
>
> b) Some declarative, safe to ignore, trust but verify markings are OK,
> but it shall be minimized.
>
> c) "common, middlebox friendly connection/packet signaling layer",
> extensibility, any communication and behavior is OK as long as it is
> explicit.

[...]

> However I do not really see problems with one of the end-point
> accepting an offer of a middlebox and communicating with the middlebox
> with a proprietary vocabulary. SPUD is clearly a good way to offer
> these improvements to end-hosts. Whether the follow up communication
> is using SPUD as a sub-transport for the signaling conversation or not
> is a question. Also this communication (when accepted) might have
> consequences, e.g. some change in charging. Obviously some kind of
> security solution is needed to authenticate the middlebox and the
> end-point, which is far from trivial.

This far-from-trivial authentication mechanism, combined with the UI/UX
concern about helping people to understand exactly who they are leaking
their metadata to, presents a really serious obstacle to deploying
something like this in a way that is safe for end users.

We need to be *reducing* the amount of metadata that our protocols leak,
not providing new channels to leak more of it.

> If we provide possibility to achieve a functionality in an explicit
> way is not it better than making network vendors to invent their own
> not so transparent solutions for the same?

We can explicitly discourage network vendors from trying to coax
arbitrary metadata out of the traffic that passes across their network.
While there are certainly some network vendors that want to do this for
purely benevolent reasons, there are far too many middleboxes that would
do this for malicious reasons, and there is no clear way that a
real-world user can be expected to tell the two apart.

Even if the users *could* distinguish "good" middleboxes from "bad" ones
(of course, different perspectives means different users will not agree
about who is "good" and who is "bad"), there are circumstances where the
user has only one network path available to them.  Providing
arbitrarily-sophisticated metadata-leakage mechanisms provides a way for
that network operator to (in an IETF-blessed fashion) demand arbitrary
metadata from the user as a precondition to the use of the network.  I
think that's not something the IETF should be supporting.

> Assuming something like c) is not happening in SPUD where do you think
> it could/should happen?

I don't think something like (c) is a good idea.  let's try to keep the
smarts (and the knowledge of both content and metadata) at the edges of
the network, and avoid blessing mechanisms that facilitate centralized
surveillance.

Regards,

        --dkg