Re: [Spud] Extensibility considered harmful? was Re: [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks

[Stephen Farrell <[e-mail]>]

Hiya,

On 01/08/16 00:33, Brian Trammell wrote:
> hi Stephen,
> 
> A couple of points inline:
> 
>> On 31 Jul 2016, at 22:13, Stephen Farrell
>> <[e-mail]> wrote:
>> 
>> 
>> 
>> On 31/07/16 20:06, Michael Tuexen wrote:
>>> So do you think that there is no need for middleboxes to support
>>> transport protocols?
>> 
>> I have no strong opinions on that.
>> 
>> I would be surprised if middleboxes wanted to support PLUS if they
>> think that QUIC is what will be widely deployed. But then I am
>> often surprised;-)
> 
> QUIC is a single transport protocol, designed for a fairly specific
> kind of interaction (H2, and things that look a lot like it;
> "fully-reliable discrete object transfer" might be a suitable name
> for this class of application).
> 
> Despite the fact that "web" and "internet" (in the lower-case,
> AP-style-guide sense) are often used interchangeably, other
> applications exist. Interactive video is one of the biggest of these
> by volume on the Internet. While it can be and has been wedged into
> HTTP (largely due to the ossification PLUS is intended to combat), it
> is a bad fit. Even the design of non-interactive video over HTTP
> implies a good deal of inefficiency, in part due to that
> "fully-reliable".

There are of course many suboptimal ways in which people can
get stuff they need to work... to work. My experience is that
people are more interested in "working" and not in "optimal."
The point here is that the web model is sufficiently close to
many many things applications need to be just usable enough. So
while I'd love to see evidence that application developers
care deeply about transport efficiency/purity, I suspect we
might all here agree that such evidence would be surprising.

> 
> If we would like the benefits of transport header integrity to accrue
> to these applications as well (and I hope I've made the case that we
> do), 

IMO that case has not been made to the point where I would
consider it justifies privacy downsides. IOW, while I am of
course in favour of endpoints being able to signal to one
another without middlebox interference, I am not at all on
side with transport header integrity being counted as a major
win in the analysis of PLUS, if that "win" inherently requires
a significant privacy cost. (And I am clearly happy to endlessly
repeat myself that in this particular case:

	extensibility == privacy unfriendly

> there are a few things we can do:
> 
> 
> (1) Design a common wire image for new transports (most of which in
> the intermediate term will probably have to slot over UDP, as QUIC
> does). This is the PLUS approach.
> 
> (2) Realize we'll probably only get one more chance to deploy a new
> transport in the next two decades, and make QUIC work well for other
> points in the application design space. This would come at a cost of
> complexity in the design and implementation of QUIC.
> 
> (3) Don't expand QUIC's design, but wedge these new applications over
> QUIC even though it's a terrible fit. This at least has the benefit
> of complying with tradition. :)
> 
> (4) Have other new transports' wire images look like a transport that
> is already widely deployed. If QUIC becomes successful, I would
> expect to see at least experiments to get other non-QUIC protocols to
> look like QUIC on the wire, a la TCP Minion.
> 

I don't myself back that set of options as the identifiable set of
possibly credible options. Minimally, option (0) is omitted, which is
to do nothing at all and to let the SPUD/PLUS idea languish as OBE.

And options (1)-(4) as presented all seem to assume knowledge of
the future - I think at least some options that ack that the
future is uncertain would need to be considered too.

> 
> Note that when discussing QUIC, it is of course important to
> distinguish the Google QUIC experiment from the protocol that the
> QUIC WG (which I presume will be formed) will standardize. So (3) and
> (4) might actually be talking about two subtly different QUICs when
> considering the transition to the standard. SPDY/H2 has at least
> shown that we know how to make this transition work relatively
> quickly (or is that speedily? ;) )

Sure. I'd hope/expect a similar dynamic to emerge within the IETF
participants working on PLUS. As you say, the h2 experience should
be one to learn and benefit from.

>> Hence my wondering about PLUS being OBE, despite SCTP etc 
>> substantially pre-dating QUIC. I do think significant port 443
> 
> Nope: HTTPS over tcp/443 does nothing at all for making it possible
> to deploy applications that don't wedge nicely atop HTTP, nothing at
> all for running those over anything but TCP, and nothing for
> transport header integrity.

I really don't agree about "nothing at all." People are very very
inventive in how they can squeeze their new applications into
whatever the hell works to get the bits from A to B. (And are also
quite willing to redefine the things about which they care to be
those that allow them to deploy applications that get stuff from A
to B with currently deployed infrastructure.)

> 
>> and QUIC deployment may change the landscape in ways that the 
>> definition and implementation of SCTP did not.
> 
> QUIC deployment did indeed change the landscape: it added 2 and 3 to
> the list above. Both are extremely suboptimal.
> 
>>> That would be an important point also when looking into the
>>> requirements of QUIC.
>> 
>> As I've said a number of times, I think the extensibility as
>> proposed at the PLUS BoF is the major privacy problem.
> 
> Speaking for myself: I've heard you.

Great. I look forward to seeing how we all figure out those trade offs.

> I continue to disagree
> (vehemently) that zero bits of extensibility is the right amount of
> extensibility, simply based on what I know about the history of bad
> engineering. However, I will say that my thinking, at least, has gone
> from unlimited permissionless definition of signals (the SPUD
> prototype, which was expressly experimental) to highly restricted
> definition of signals (PLUS as described in the charter) to
> restricted definition of signals with severely limited header /
> codepoint space, to address privacy as well as overhead concerns.
> This implies a tradeoff in the ability to fix things we got wrong
> later, of course.

Yes. Trade-offs are like that. Noting that in this case, I don't
think anyhting bigger than a miniscule space of codepoints can be
part of a privacy friendly solution - once there are enough codepoints
that the two endpoints in a randomly selected transport connection can
unambiguously agree to (ab)use a codepoint as their chosen signal, then
the game is over. ISTM, that means even a very very few bits can be
very privacy unfriendly.

> 
>> I've also said that I'm so far neutral on a non-extensible way of
>> exposing some transport information to the path (if one exists and
>> is useful, which I also don't claim to know).
> 
> There appears to us to exist a useful set of signals that are
> transport-agnostic, the minimal set of which we hope to have a full
> description of (with bits, yay!!) shortly, as in my message to
> Eliot.

Consider my breath bated:-)

> 
>> I would however be opposed if "transport information" is so broadly
>> interpreted as to include identifiers or generic attributes of the
>> endpoints that are not otherwise exposed.
> 
> As would I. 

I'm totally unshocked at that:-) Seriously though, I do fully
accept the bone-fides of all of the main disputants here.

> I am frankly a little baffled as to who you think is
> proposing this interpretation.

If we provide enough bits to allow such mappings, then those will be
abused. MSISDN enrichment as a popular mechanism tells me that if we
provide a way to do even the silliest stuff, then some folks will do
just that. (Because it's not silly from their POV.)

> 
>> And that's before we consider the coercion attack raised at the BoF
>> and (so far) briefly mentioned in Brian's draft.
> 
> As noted, I'm convinced the threat posed by coercion attack is very
> real, today. 

That's a newish one for me so I need to learn more about it. (Not having
been a student of net neutrality:-)

> I still don't buy the assertion that PLUS expands this
> surface.

I think you and I earlier disagreed as to whether or not standardising
X-that-was-already-possible does or does not expand the attack surface
for threats-due-to-X. I do think a standard has at least that effect.

Cheers,
S.

> 
> Regards,
> 
> Brian
>