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

[Kyle Rose <[e-mail]>]

On Sat, Aug 6, 2016 at 8:38 AM, Stephen Farrell <[e-mail]>
wrote:

>
> Hi Kyle,
>
> Again, sorry for the slow response. But we're likely evens on that:-)
>

And again for me. :-)


> > Perhaps ironically, this argument has basically re-convinced me that
> > privacy at the routing layers on the public internet is hopeless.
>
> FWIW, I never agree that privacy is hopeless.
>

I'll agree that "hopeless" is a bit hyperbolic, but the degree of
hopelessness depends on what the threat model is. For coercion of single
bits, I'm willing to stand by that phrasing.


> And even if it, in some sense, were, I firmly believe that we can
> choose to make the Internet worse wrt privacy or to not do that.
>
> So even if we cannot "solve" the "privacy problem," there is still
> an onus on us (as good engineers) to not make that worse and to define
> tooling that would allow folks to make things better should they later
> choose to deploy those tools. (That last has to be done quite
> selectively though, only after some tool looks like it might get at
> least some real traction, as otherwise we enter the realm of speculative
> research and not engineering.)
>

A necessary element to the approach you outline is having a coherent vision
for what we want a privacy-first internet to look like, and how we would
get there. I don't think an incremental approach based on RFC 6973 and
derivatives is going to achieve that because so far what I see is a blanket
prohibition on extensibility out of fear that some mechanism could be used
for nefarious purposes, when what protocol designers need is guidance on
what they *can* do.

The threat model in 7624 may be a good starting point for this, but the
prohibitions implied there need to be inverted into a set of design
guidelines that the IAB considers acceptable. I don't think the black box
approach to standards approval is the right one, but it feels like that's
where we are without explicit guidance.

Furthermore, during the transition phase between the internet of 2016 and
the internet of 2036, we can't hamstring all standards development because
not all the building blocks for the privacy-first internet are in place.
Users have needs, and if they aren't fulfilled by the IESG, users will
migrate to getting their standards elsewhere, and everyone will be worse
off from the resulting fragmentation. Our sweet spot is not standing
athwart all development, yelling "stop!": it's balancing individual user
needs and wider privacy concerns and standardizing something that will work
well enough that people use it, that don't materially worsen the existing
privacy problems, and that we can show will improve such things over time.
(Emphasis on "show".)

We don't have dictatorial control over the internet, but a lot of these
discussions seem to implicitly frame the problem that way. If we don't give
users what they want, we risk becoming irrelevant.

Concern about one bit seems not to fit with a balanced approach; worrying
about a generic key/value mechanism not under endpoint control probably
does. Where do we draw the line, and why?


> Also - I'm not sure what you mean by "routing layers" nor how that
> maps to the transport issues SPUD/PLUS is trying to address.
>

Sorry, by "routing layers" I mean essentially the metadata that must be
made known to third-party network elements in order to direct packets to a
logical destination: DNS requests and the destination address in a packet
are the most obvious of these, but it also includes things like SNI for
certain layer 3 routers and load balancers.

I think we would both (all?) agree that today there is too much public
metadata, and that metadata is not narrowly directed at only those network
devices that actually need it. I would argue we need to start scoping out
possible reductions in this envelope, both in a v6 internet and in an ideal
world with the protocols we really want. We can then express balanced
guidance on privacy protections for the internet we have, allowing
standards development to continue for users' real-world needs, while also
moving forward in the research/experimental direction toward the internet
we want.

Constraining standards development in the internet we have based on what's
possible in the internet we want, but haven't scoped or defined, and that
we might get at some undetermined point in the future, is not acting in the
interests of users.


> In that and many cases though the other endpoint would not (in general)
> know of the silly addressing scheme. If we standardise such, then all
> endpoints know of the silliness and the situation is worse.
>

Understood, but the even/odd address thing is something any ISP or
government can unilaterally implement and enforce for all of its own users:
it requires no further standards work. At least with IPv6, I'd argue the
only unilateral mitigation for this kind of concern is to shut off the
network. So including this in the threat model as anything other than
"accepted risk" effectively shuts down all discussion of protocol
extensibility.


> I'm also not sure that coercion is the right term for this part of the
> problem. At least as I envisage things, if a middlebox can ever add a
> standardised extensible value to the flow, then we are likely to run
> into these issues.


I read your initial objection as 'the ISP can make the user add this
information, or a blank space for fill-in by path elements, to its PLUS
header before signing'. Coercing users into adding either the information
itself or a blank space for the information (such that modifications to
that value are allowed by recipient stacks, even in the presence of a MAC
for the keys and all the other values) seems like the general threat here.

For each specific threat, the two relevant follow-up questions seem to be:

(1) How does this extension make privacy more difficult to achieve than it
is today?
(2) How does this extension make privacy more difficult to achieve than it
would otherwise be under this new internet we'll have deployed X years from
now, and is the objection relevant if the protocol stack will look entirely
different?

I am using a comparative ("more difficult") rather than an absolute (e.g.,
"unachievable") because there are other, heavier-weight approaches like TOR
that can give us a lot of what we want on top of the public internet of
today.

It's very unclear to me that SPUD/PLUS can work and
> not allow such addition whilst also not introducing new round-trips.
> But we'll need to wait and see what the PLUS proponents actually
> propose before we can really analyse that.
>

I think the burden is on both sides of the argument: the PLUS proponents
need to demonstrate a need and a protocol that narrowly achieves that need,
and privacy advocates need to come to some public agreement on what degree
of extensibility is okay, and formalize that so protocol designers aren't
shooting arrows in the dark or at a moving target.

Kyle