Re: [Udp35] Snowden and SPUD

[Brian Trammell <[e-mail]>]

(copying stackevo again as the successor to udp35)

> On 20 Jul 2015, at 18:47, Michael Welzl <[e-mail]> wrote:
> 
> 
>> On 20. jul. 2015, at 17.14, Jana Iyengar <[e-mail]> wrote:
>> 
>> A few offhand thoughts:
>> 1. Snowden is not part of the SPUD conversations, so it's easy to be confused about what the current thinking is. The current thinking is _not_ about simply "leaking" information to middleboxes. The details are important here -- what information is being transmitted is, as a first approximation, the same stuff that currently middelboxes get out of TCP and ICMP (if those worked as intended). If there's more info, it's going to be debated heavily for privacy concerns.
>> 2. Snowden can engage in IETF SPUD meetings, and I'm sure he'd be welcome to them.
>> 3. It's all about rough consensus, not an individual's opinion.
> 
> I agree about all that - just wanted to hear thoughts (and if I got his message right)
> 
> 
>> 4. Finally, and I have been concerned about this for a while now: I've always said that the SPUD prototype should be distinct in name from the SPUD effort. The prototype is the face of the effort and represents current thinking for anyone glancing at this stuff, and it seems scary and dangerous. We'd all be concerned if the SPUD prototype were the actual protocol deployed, but that's supposedly not going to be the case. Which begs the question: why spend any time on a protocol that is destined to not make it? Why not actually figure out a protocol that *might* and then see how to build it out?
> 
> Okay, I guess it’s time for me to say what I think about SPUD.
> 
> There are two parts here: the later rolled-into-SPUD AE(C)ON-and-before (flow metadata and whatever else it was called) ideas from Cisco. These are what they are, with their pro’s and deficiencies, and this is not what this email is about. I think we should focus on the original idea, which is about getting through middleboxes by “playing nice”. Here I think SPUD is trying to solve a problem that can’t be solved by protocol design. It’s not a design problem, it’s an incentive problem.
> 
> Consider the discussion about connection setup/teardown that happened on the SPUD mailing list some time ago. Someone said (s)he thinks it’s useless because in the middlebox, they will need a timer anyway, as one can’t simply trust the teardown message to arrive. Well, people do have more trust in TCP it seems … it seems to me that it’s a story of incentives and trust much more than it’s a story of how the protocol looks.
> 
> Here’s a thought experiment. Three (wrong) assumptions: 1) Assume, for a second, that native protocols would have a 50% chance of passing on the Internet (I think that’s too optimistic, but that’s not the point here). 2) Assume that browsers could send out native protocols.  3) Assume that QUIC would be such a native protocol.
> 
> Q: what would happen to the non-supportive paths?
> 
> I think we would quickly see this 50% number grow - because there’s a customer need associated with QUIC. People want it because it makes their browsers faster, as simple as that! Plus, it will earn trust points over time because it’s only generated in user space, comes from browsers, comes from Google, has been wider and wider tested….
> 
> Now, assume that QUIC would become a general-purpose carrier. All kinds of applications would start using it. Everything would be multiplexed over QUIC. What would middleboxes do? They would start looking deeper into QUIC, right? Same problem again!

Except they can't, because QUIC encrypts everything except the things that are explicitly exposed to the middleboxes. This is the intention with SPUD as well -- we redraw the network/transport layer boundary, this time with a big fat red marker that says go ahead, bruteforce my keys.

> The point of this story: I think you can’t make a general-purpose carrier that “plays nice” and convinces middleboxes that all is fine. That’s a bit too much Jedi magic IMHO.  What you can do is to try to convince them, service by service (“faster web browser”, ..). Now, here, Joe Hildebrand had a “carrot and stick” story that didn’t convince me - but perhaps I just never got it. Anyway, that’s the crux of the matter: IF AND ONLY IF the carrot - stick story makes sense, SPUD makes any sense. Else, you have to create a greater incentive, as QUIC will certainly do, but only for browsers.

The stick is "go ahead, bruteforce my keys."

The carrot is "here is something I am willing to tell you and you have to decide on your own if you trust me.

The axe-head attached to the stick is "if you don't let this through, then you get a giant pile of entropy that tells you nothing."

Cheers,

Brian