Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks

From: Eliot Lear <[email-masked]>
Date: Mon, 1 Aug 2016 12:28:40 +0200

Hi Christian,

On 7/31/16 10:10 PM, Christian Huitema wrote:
> The draft mentions the IPv6 flow-ID, but creative intermediaries might
> also manipulate the TOS fields, so maybe there should be a subsection
> describing that too.

Just so that we're clear, the TOS fields, and in particular DHCP were
designed so that they could be overwritten (mostly erased), as required,
by intermediaries.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 1 Aug 2016 15:56:32 +0200

Christain points out to me that I have DHCP on the brain:

> designed so that they could be overwritten (mostly erased), as required,

s/DHCP/DSCP/

Eliot

---

From: Tom Herbert <[email-masked]>
Date: Mon, 1 Aug 2016 07:59:24 -0700

On Sun, Jul 31, 2016 at 11:34 PM, Eliot Lear <[email-masked]> wrote:
>
>
> On 7/30/16 9:59 PM, Tom Herbert wrote:
>>
>> No, it's not. In fact, exposing flow start/stop information is a good
>> example of something that facilitates intrusiveness by middleboxes at
>> the transport layer.
>>
>> The purpose of exposing this information is to allow network devices
>> to track connections, but connection tracking in the network is
>> fundamentally flawed since there is no requirement that all packets of
>> a connection go any single network device (i.e. the Internet is packet
>> switched not circuit switched).
>
> Except that I will bet you that over 99.999% of connections do, and that
> this is particularly sufficient for home routers.
>
Eliot,

If that number it is correct it is only because home routers have
ossified the Internet in that regard, not because the standard was
ever changed to require it. Desktops sitting behind home routers is no
longer a sufficient model for the Internet; mobile devices are
currently predominant and the Internet needs to adapt accordingly.

Consider that mobile devices are multihomed having at least two
network connections. We want the ability to seamlessly switch between
networks (say from wifi to mobile) or between mobile networks as we
drive down the road. Performing 3WHS is very expensive on mobile
(literally for some of our users), so we need connections to survive
across these path changes. If we hide the transport layer from the
network devices (e.g. from home routers) then they can't enforce the
single path assumption. In fact, once we disassociate location
(addressing) from connection endpoint identification (like described
in TOU) then connections should be able survive even across an address
change and between two completely providers. This is of huge value to
our users and IMO justifies encrypting the transport layer.

Tom

---

From: Eliot Lear <[email-masked]>
Date: Mon, 1 Aug 2016 17:08:57 +0200

Hey Tom,

On 8/1/16 4:59 PM, Tom Herbert wrote:
> If that [99.999%] number it is correct it is only because home routers have
> ossified the Internet in that regard

I realize that people have ossification on the head, but I'm sure you
recognize that the right answer here is that most people only have a
single connection into their homes.  For those who have more than one,
the two either are disconnected networks or they come together in the
same box.  We do not have the routing infrastructure today in place to
multihome to your laptop/iPhone/tablet/Android/FB phone, something I
deeply regret we have not yet worked out. Maybe some day.

> , not because the standard was

But the way this is done is through multiple pesistent transport
connections bound off of separate L3 local addresses.  We have attempted
to do otherwise through MIPv6 and LISP-MN.  Not widely deployed, and
even were they so, it is probably sufficient for something like the LISP
header to be above PLUS (think about that until you're 103)!

Eliot

---

From: Tom Herbert <[email-masked]>
Date: Mon, 1 Aug 2016 08:56:01 -0700

> single connection into their homes.  For those who have more than one,

Well, I'm sitting here in my home looking at my Nexus 6 and I can
confirm that it is attached to Internet my via Comcast wifi as well as
Verizon's mobile network. So my smart phone is definitely a multihomed
and I definitely have multiple connections into my home. Right now I'm
using the wifi link, but if I walk into my backyard out of range then
I don't want the device to have to restart all my TCP connections when
switching to the mobile network. Neither do I want to have to create
2x connections like in MP-TCP just because I might at some point walk
into my back yard (it's kind of gloomy right now so I don't think I'll
be doing this anyway).

> deeply regret we have not yet worked out. Maybe some day.
We don't need routing infrastructure to change and we are really not
asking for any changes in the network other than they forward UDP
packets, respect E2E protocols, and otherwise implement the Internet
standard. The transport layer is being changed to facilitate
multihoming. Please look at connection identifiers in QUIC and
disassociated location in TOU ( draft-herbert-transports-over-udp) to
see how this is being done.

> header to be above PLUS (think about that until you're 103)!
Those some of the possible ways to do handle multihoming, but by no
means does this define the complete solution space. There is still
room for innovation in alternatives as I pointed out above.

Tom

---

From: Ted Hardie <[email-masked]>
Date: Mon, 1 Aug 2016 11:56:57 -0700

On Sun, Jul 31, 2016 at 6:01 PM, Stephen Farrell <

>
> 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
>
>
Stephen, someone naively coming across this statement in the record will
think you mean that any extensibility is privacy unfriendly.  Obviously,
you have championed the ability to shift cryptographic algorithms as needs
change, which requires extensibility of specific forms.   Lots of other
work requires extensibility to be useful at all (imagine if the tag space
of the web had been frozen in 1993).

I should greatly appreciate you reformulating this into something that
actually matches your meaning.  That would likely be useful; this is not.

thanks,

Ted

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 1 Aug 2016 14:56:48 -0500

Hi, Tom,

> into my back yard (it's kind of gloomy right now so I don't think I'll

I'm not going to guess what wireshark would show on your home network or on
Verizon's, but I'm having a hard idea understanding how a TCP connection
identified by a 5-tuple that includes a local address from your wifi routed
through Comcast stays active when you get in a car and drive away, so that
the only active interface on your smart phone now has a local address that
is routed through Verizon.

Mine don't (admittedly, mine are Comcast and T-Mobile), but. When I walk to
my car and get away, streaming media I was listening to in the house stops
when I run out of wifi range.

Are you sure you're not using (for instance) applications which open new
TCP connections periodically?

Spencer

> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud
>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 1 Aug 2016 13:06:49 -0700

> is routed through Verizon.
TOU will negotiate a session identifier (similar to connection
identifier) in QUIC. With this the TCP endpoints no longer use the
5-tuple to identifier the connection, they use the session identifier.
This provides unambiguous connection identification that is
independent of addresses or encapsulating UDP ports (the most
immediate problem this resolves is NAT state remapping). Strong
security is required to prevent connection hijacking and there are a
couple of other caveats. Please look as section 3 in
draft-herbert-transports-over-udp for details.

Tom

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 1 Aug 2016 15:10:26 -0500

Hi, Tom,

On Mon, Aug 1, 2016 at 3:06 PM, Tom Herbert <[email-masked]> wrote:

> >> >> If that [99.999%] number it is correct it is only because home
> routers
> >> >> have

AH - I didn't realize you were talking about your proposal. I've read that.
I lost any reference to it in the post I replied to - hence my confusion.

Thanks for the clue.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 1 Aug 2016 20:15:57 +0000

On Monday, August 1, 2016 1:10 PM, Spencer Dawkins wrote:
>
> AH - I didn't realize you were talking about your proposal. I've read that. I lost any
> reference to it in the post I replied to - hence my confusion.

The question was whether it is a good idea to have special marks for packets that "start a connection," and specifically for packets sent over UDP by encrypted transports. Tom's point is that this will create breakage in many conditions, such as multi-homed nodes. I can see at least two scenarios in which we could see breakage with QUIC:

1) Client is sitting behind a nonplussed NAT. The QUIC session with the server becomes silent for a short period, and the client's NAT releases the UDP mapping. The client then sends more data. The NAT will assign a different port mapping. The server will use the connection-ID field in the QUIC header to route the packets to the right server, and automatically repair the connection. Suppose now that somewhere on path, maybe at the ISP router, some piece of software traces the connections and relies on "start of connection" marks. The "repair" packet comes from a different UDP port, and does not carry any "start" mark. Will it be dropped?

2) Client is sitting on a multi-homed network, managed by outgoing NAT. At some point, NAT management causes the packets to the server to be routed through the "fall back" ISP. The packets reach the server, the connection-ID filed does its magic, and the connection is automatically repaired. But of course, the routers on the new path don't see any "start of connection" mark.

There are probably more cases, but these two can happen today, with shipping code and existing hardware. The NAT mapping refresh, in particular, is quite common. This is why I much prefer "implicit start" processes to "explicit marks."

-- Christian Huitema

---

From: Tom Herbert <[email-masked]>
Date: Mon, 1 Aug 2016 13:52:12 -0700

> There are probably more cases, but these two can happen today, with shipping code and existing hardware. The NAT mapping refresh, in particular, is quite common. This is why I much prefer "implicit…
The question is also whether we need to send an explicit "end
connection" signal. Network devices want this to know when to free
their connection tracking state, but in a multipath Internet I don't
readily how this would be a useful signal either.

Tom

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 1 Aug 2016 21:55:46 +0100

Hiya,

> actually matches your meaning.  That would likely be useful; this is not.

Sorry if there was context lacking and happy to try elucidate
further (and please do feel free to help improve my description of
the issue)...

In the specific case of exposing higher layer information about well
protected (e.g. encrypted) traffic to lower layers, (whether via an
interface from the higher layer, or via addition by the lower layers)
I believe any extensible mechanism for that kind of interface severely
risks being extremely privacy unfriendly. And the transport layer may
be the worst possible case of such an extensible higher/lower layer
interaction as it by definition spans the full "width" of the network.

I think the main reason is that there would be significant pressure
and temptation to try support non-technical policies being enforced
at one place in the network based on information provided at another.
In this case, by "non-technical," I mean any information not
absolutely necessary for the correct operation of the lower layer.
That's a term and definition I'm sure could be improved, and I'm also
sure there could be borderline cases.

But there would immediately also be cases that are nowhere near any
border... such policies would almost certainly demand methods to expose
personally identifying information or identifiers that can be easily
(re)identified as such. That would directly enable the kind of
meta-data collection and tracking that the IETF has agreed is an
attack in BCP188. (I assume here that no relevant lower layers "need"
PII to operate correctly - if they do, they are probably broken:-)

But another and possibly even worse (ab)use case might signal that the
person associated with a flow is a member of some set of people, for
example, over-18, a member of the ruling party, or of some minority.
The consequences of standardising that kind of extensibility in a way
that could allow such "policy enforcement" at essentially any place
on the Internet is for me supremely scary.

While there do doubtlessly exist use-cases for such extensibility in
this context that initially appear reasonable, the potential impact of
the abuse cases, and my own opinion of their probability of occurrence
being approx 1.0 at some place(s) and times on the big-I Internet for
me very much outweighs any potential utility from non-abuse cases of
this particular kind of extensibility. As an aside, I fully accept
that folks arguing for non abuse-cases of extensibility are doing so
with good intentions. I think this is just an unusual case where our
normal ways of engineering extensibility are way more dangerous than
usual. (*)

In the case of the proposed charter at the BoF, the use of an IANA
registry seems particularly unwise to me as in addition to being
open to pressure to formally register privacy-unfriendly codepoints,
any IANA-based scheme would also allow for squatting on codepoints,
which we know can become a fait-accompli. I don't see any way in
which IETF/IANA processes could resist the pressure to provide such
"policy" support. I also cannot think of a non-IANA extensibility
mechanism that could work here and not have the privacy downsides.

And lastly, there is a significant difference here between existing
non-standard methods for injecting the above kinds of information
and a world in which we have standardised such extensibility. The
status quo may allow for such injection but the full horror of the
worst abuse-cases here would require that the abuse-case information
flow from end-to-end unimpeded (or almost end-to-end) so reliably
abusing that kind of information does I think require a standard.

Hopefully that's clearer, (it's definitely longer;-) and again, I'd
really welcome crisper and better text to describe these issues as
I'm sure it's a discussion that will recur at other times and places.

Cheers,
S.

(*) The "usual" dangers of extensibility are I guess complexity and
loss of interoperability, exemplified in the current debate about TLS
ciphersuite structure and TLS version intolerance.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 1 Aug 2016 21:02:51 +0000

> readily how this would be a useful signal either.

The concern about the "end" signals is potential misuse -- something similar to spoofing TCP RST -- think "man on the side" attacks. The spoofed packets will not fool the endpoint, but they can cause intermediate systems to drop state, and effectively force an ongoing connection to stop. Any design would have to somehow mitigate this spoofing attack.

-- Christian Huitema

---

From: Eliot Lear <[email-masked]>
Date: Tue, 2 Aug 2016 00:02:55 +0200

> readily how this would be a useful signal either.

Look at that as an optimization.  We always have to handle the case
where the device drops dead or a process dies.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 2 Aug 2016 09:47:41 +0200

Hi Tom,

> draft-herbert-transports-over-udp for details.

TOU is similar in many ways to what HIP did in the early days, and the
HIP developers had a pretty cool demo of it.  The threats we faced back
then were nowhere near as advanced as they are today, nor are they as
prevalent.  There is not a single platform upon which you base your
software that hasn't been attacked successfully, although some have been
attacked more regularly than others.

Let me be as clear as I possibly can be: I view a protocol that doesn't
offer an answer to the question “who initiated the communication” as
unsafe to be deployed on the Internet.  I will make another bet with
you, that at least half of your user base is running on old code with
known vulnerabilities.  This is even more critical on battery-powered
constrained devices, where a broad-scaled and sustained DDoS attack
could drain those batteries and harm a lot of people, in a short period
of time.

If there are tradeoffs to be made in mobility design because of this,
then those tradeoffs should be made.  But before you view it in that
light, lengthy research has demonstrated that RF requires repeated
selection queries to determine what is available.  That is the work done
by SCTP researchers such as Randy Stewart, and so mobility isn't being
traded off at all.**

You are seeking formal agreement of network behavior.  I am seeking an
answer to my question.  If we formalize the answer to that question,
then you have what you want and I have what I want.  I've been told that
QUIC has such an answer to my question, which is good.
I'd like to understand how that is accomplished in a secure manner. 
Certainly integrity protecting the 5-tuple and any sequence #s sounds
like a good idea, to say the least, if it can be efficiently accomplished.

Eliot

---

From: Tom Herbert <[email-masked]>
Date: Tue, 2 Aug 2016 10:03:31 -0700

On Tue, Aug 2, 2016 at 12:47 AM, Eliot Lear <[email-masked]> wrote:
> TOU is similar in many ways to what HIP did in the early days, and the HIP
> developers had a pretty cool demo of it.  The threats we faced back then
> were nowhere near as advanced as they are today, nor are they as prevalent.
> There is not a single platform upon which you base your software that hasn't
> been attacked successfully, although some have been attacked more regularly
> than others.
>
> offer an answer to the question “who initiated the communication” as unsafe

Eliot,

With that view IP is completely unsafe and shouldn't be deployed since
IP source addresses can and are trivially spoofed. Session identifiers
with security that authenticates the peer provide an unambiguous and
far more trustworthy answer to the question about who initiated a
communication.

> to be deployed on the Internet.  I will make another bet with you, that at
> least half of your user base is running on old code with known
> vulnerabilities.  This is even more critical on battery-powered constrained
> devices, where a broad-scaled and sustained DDoS attack could drain those
> batteries and harm a lot of people, in a short period of time.
>
Yes, we all want DDoS prevention. But my application needs to be able
to run securely on _every_ network on the planet. Unless you can prove
that every one of these networks implements some common standard DDoS
mitigation and other required security mechanisms, then I really have
no choice but to treat the network is an insecure black box, assume my
applications are at risk, and implement all of my own security.

> If there are tradeoffs to be made in mobility design because of this, then
> those tradeoffs should be made.  But before you view it in that light,
> lengthy research has demonstrated that RF requires repeated selection
> queries to determine what is available.  That is the work done by SCTP
> researchers such as Randy Stewart, and so mobility isn't being traded off at
> all.
>
> answer to my question.  If we formalize the answer to that question, then
> you have what you want and I have what I want.  I've been told that QUIC has
> such an answer to my question, which is good.
> Certainly integrity protecting the 5-tuple and any sequence #s sounds like a
> good idea, to say the least, if it can be efficiently accomplished.
>

To be clear I am not seeking formal agreement of universal network
behavior (I believe that is supposed to be already covered by
networking layer standards), we are trying to resolve protocol
ossification to move the Internet forward. Protocol ossification
happens in the network when devices anonymous to the endpoints attempt
to interpret transport layer information to some effect and does this
without the auspices of any standard. Usually this is with benevolent
intent, but the problem is that when the end points attempt something
"new" (e.g. TCP fast open, new TCP options, using SCTP, trying sustain
connections between mobile networks) the network can break E2E
communication in a variety of ways because the communication doesn't
match _its_ concept of what a "legal" communication is. Encrypting the
transport layer is the only proposed solution to defeat protocol
ossification.

I don't believe the PLUS proponents will argue against the rationale
of encrypting the transport layer. Protocol ossification is a real
problem and we can demonstrate several examples where it has thwarted
innovation of transport protocols. What is at question is what
transport layer information hosts are either required or should
voluntarily "give back" once the transport layer is encrypted. IMO,
from the perspective of a large application provider, the default
answer is currently none. If signaling transport layer information
were to be explicit between hosts and network devices, and there is an
established trust relationship with an agreement the spells out the
precise use of the information and the scope of information
propagation-- then I think there is a much better chance to achieve
the cooperation necessary to solve things like the mobile DDoS problem
you mentioned above. I think the mobile guidance draft
(draft-flinck-mobile-throughput-guidance) is on the right track in
this regard, it make signals explicit and non-anonymous (although I
don't like the part where they allow middleboxes to parse and modify
TCP options, IMO this, as well as PLUS, should be using HBH options
for host-network signaling). Explicit non-anonymous signaling can also
adhere to the E2E model if network devices are expressly acting on
behalf of a host with specific directives to do that.

All of this is just my opinion, but it is why I had to hum no at the BOF...

Thanks,
Tom

---

From: Brian Trammell <[email-masked]>
Date: Wed, 3 Aug 2016 11:07:32 +0200

hi Stephen,

Thanks for this; I understand the concerns you have better, now. I have a couple of questions, and one major point of remaining confusion, inline, below:

> On 01 Aug 2016, at 22:55, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

(Aside: I'll note again that this isn't the proposal. Transports expose transport layer information that used to be available from inspection of now-encrypted transport headers. Applications can help with this, and of course the APIs should allow applications control over what gets said.  Preventing linkage between that information and higher-level data (e.g. making sure that certain kinds of content aren't commonly tagged so as to be fingerprintable) is a matter for careful design of the vocabulary. It's clear we disagree as to whether it's possible to carefully design a vocabulary that is large enough to be useful. I can't (yet) prove that it is, but I strongly suspect so.)

> sure there could be borderline cases.

Of course, there's a fair range of opinion hiding behind that "absolutely"; which point along that continuum do you mean? *All* of the extended information we envision applications exposing to the path via PLUS are intended to improve the performance and/or economy of the network. Some of them we're pretty sure will work, while others will require more experimentation to know. Let's say we're wildly successful and PLUS signaling allows a network to operate at a given capacity with M% less spectrum (due e.g. to unwanted traffic rejection before the RAN), or reduce user-perceived latency by N% (loss/latency signaling and other smarter queue management), or use P% less battery in aggregate (due to better state management), or reduce operational diagnostic costs by Q% (in-band measurement), with respect to an approach where we have fully encrypted transport headers. What are the M, N, P, and Q values that divide "absolutely necessary for correct operation" from "non-technical information exposure"?

> this particular kind of extensibility.

In your estimation, is the probability of occurrence of this kind of abuse of the present protocol stack, at some places and times on the big-I Internet, currently less than 1.0? (I know you think this question is irrelevant. I'd just like to how bad you think things are today.)

> As an aside, I fully accept

Now I'm really confused.

Of course this pressure exists. Are you arguing that a vocabulary registry for a signaling protocol which requires a standards action to modify is necessarily less resistant to this pressure than the standards process itself? If so, can you explain the mechanism by which that is the case? Because they seem like exactly the same thing to me.

> which we know can become a fait-accompli.

How is squatting on codepoints not equivalent to the abuse of widely deployed protocols and implicit behaviors thereof?

> I don't see any way in
> "policy" support.

When a registry is requires a standards action to add to, how is this statement not equivalent to "The IETF standards process is incapable of resisting the pressure to provide such policy support"? This seems quite pessimistic, even to me.

> I also cannot think of a non-IANA extensibility

I at least fully agree with you that the IANA-managed extensibility is as dangerous as or less dangerous than non-IANA managed extensibility. So at least we have that. :)

Thanks, cheers,

Brian

---

From: Kyle Rose <[email-masked]>
Date: Wed, 3 Aug 2016 07:00:01 -0400

> on the Internet is for me supremely scary.

I've been thinking and having offline conversations about this for a few
days. (Sorry to lob a bomb and then disappear. Stupid work.)

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

If your threat model concerns itself with coercion over a single bit of
information, then the very architecture of the internet is completely
broken: a government can simply issue even addresses to over-18's and odd
addresses to under-18's. Enforce it at the ISPs and you're done.

Continuing this line of thought, with IPv6 it seems pointless to worry
about end-to-end survival of any metadata shorter than 64 bits (the host
ID), which leaves 2^31 identifiers per human should a government want to
enforce specific assignment of those addresses by ISPs. There's already far
too much space baked in at the IP layer for a threat model that includes
coercion of small amounts of metadata.

A good argument might start with, "Twenty years from now, perhaps the
internet will look a lot different than it does today." Which is something
I've said myself, based on conversations with you and Dave Plonka. But I
think we need lots more details on what that would actually look like to
justify vetoing all extensibility mechanisms from now until that day comes.
Worry doesn't seem sufficient justification given the implications of this
kind of threat model and the demonstrable usefulness of extensibility: the
architecture of a privacy-first internet needs to be fleshed out.

For instance, what would an internet without plaintext source addresses
look like? Without BCP38, what would we do to address (what are today
spoofing-based) DoS attacks? I'm sympathetic to architectural changes like
this, as from a security perspective the source address is simply a hint:
it's 128 bits that the sender can almost always lie about. But an actual
proposal is needed to know if an internet without them is even feasible.
And even if we confirm that this new internet is deployable, there's still
the whole problem of actually deploying it. If it requires starting from
scratch as IPv7 because it won't interoperate with v6, it's going to be
really hard to get adoption without using v4/v6 as a substrate, like TOR.
At which point we might as well return to the approach of running smaller
private internets over the public internet.

I think there still are some good arguments being made that exposing any
transport signaling to middle boxes creates further implicit ossification
around multipath that need to be explored further, but at this point I'm
unconvinced by the coercion argument given the internet we have.

Kyle

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 6 Aug 2016 13:23:44 +0100

Hi Brian,

Sorry for the slow response...

On 03/08/16 10:07, Brian Trammell wrote:
> hi Stephen,
> 
> Thanks for this; I understand the concerns you have better, now. I
> have a couple of questions, and one major point of remaining
> confusion, inline, below:
> 
>>>> 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 
>>> Stephen, someone naively coming across this statement in the
>>> record will think you mean that any extensibility is privacy
>>> unfriendly.  Obviously, you have championed the ability to shift
>>> cryptographic algorithms as needs change, which requires
>>> extensibility of specific forms.   Lots of other work requires
>>> extensibility to be useful at all (imagine if the tag space of
>>> the web had been frozen in 1993).
>>> 
>>> I should greatly appreciate you reformulating this into something
>>> that actually matches your meaning.  That would likely be useful;
>>> this is not.
>> 
>> In the specific case of exposing higher layer information about
>> well protected (e.g. encrypted) traffic to lower layers, (whether
>> via an interface from the higher layer, or via addition by the
>> lower layers) I believe any extensible mechanism for that kind of
>> interface severely risks being extremely privacy unfriendly. And
>> the transport layer may be the worst possible case of such an
>> extensible higher/lower layer interaction as it by definition spans
>> the full "width" of the network.
> 
> (Aside: I'll note again that this isn't the proposal.

That's not clear to me. I really can't see how one does what would
work for f/w folks without running into this risk. I fully accept
that many proponents of PLUS don't want to see the privacy-unfriendly
outcome I fear.

> Transports
> expose transport layer information that used to be available from
> inspection of now-encrypted transport headers. Applications can help
> with this, and of course the APIs should allow applications control
> over what gets said.  Preventing linkage between that information and
> higher-level data (e.g. making sure that certain kinds of content
> aren't commonly tagged so as to be fingerprintable) is a matter for
> careful design of the vocabulary. It's clear we disagree as to
> whether it's possible to carefully design a vocabulary that is large
> enough to be useful. I can't (yet) prove that it is, but I strongly
> suspect so.)

Determining if such a safe vocabulary is or is not possible seems
like a fine bit of work to undertake for those keen on PLUS.

> 
>> I think the main reason is that there would be significant
>> pressure and temptation to try support non-technical policies being
>> enforced at one place in the network based on information provided
>> at another. In this case, by "non-technical," I mean any
>> information not absolutely necessary for the correct operation of
>> the lower layer. That's a term and definition I'm sure could be
>> improved, and I'm also sure there could be borderline cases.
> 
> Of course, there's a fair range of opinion hiding behind that
> "absolutely"; which point along that continuum do you mean? *All* of
> the extended information we envision applications exposing to the
> path via PLUS are intended to improve the performance and/or economy
> of the network. Some of them we're pretty sure will work, while
> others will require more experimentation to know. Let's say we're
> wildly successful and PLUS signaling allows a network to operate at a
> given capacity with M% less spectrum (due e.g. to unwanted traffic
> rejection before the RAN), or reduce user-perceived latency by N%
> (loss/latency signaling and other smarter queue management), or use
> P% less battery in aggregate (due to better state management), or
> reduce operational diagnostic costs by Q% (in-band measurement), with
> respect to an approach where we have fully encrypted transport
> headers. What are the M, N, P, and Q values that divide "absolutely
> necessary for correct operation" from "non-technical information
> exposure"?
> 
>> But there would immediately also be cases that are nowhere near
>> any border... such policies would almost certainly demand methods
>> to expose personally identifying information or identifiers that
>> can be easily (re)identified as such. That would directly enable
>> the kind of meta-data collection and tracking that the IETF has
>> agreed is an attack in BCP188. (I assume here that no relevant
>> lower layers "need" PII to operate correctly - if they do, they are
>> probably broken:-)
>> 
>> But another and possibly even worse (ab)use case might signal that
>> the person associated with a flow is a member of some set of
>> people, for example, over-18, a member of the ruling party, or of
>> some minority. The consequences of standardising that kind of
>> extensibility in a way that could allow such "policy enforcement"
>> at essentially any place on the Internet is for me supremely
>> scary.
>> 
>> While there do doubtlessly exist use-cases for such extensibility
>> in this context that initially appear reasonable, the potential
>> impact of the abuse cases, and my own opinion of their probability
>> of occurrence being approx 1.0 at some place(s) and times on the
>> big-I Internet for me very much outweighs any potential utility
>> from non-abuse cases of this particular kind of extensibility.
> 
> In your estimation, is the probability of occurrence of this kind of
> abuse of the present protocol stack, at some places and times on the
> big-I Internet, currently less than 1.0? (I know you think this
> question is irrelevant. I'd just like to how bad you think things are
> today.)
> 
>> As an aside, I fully accept that folks arguing for non abuse-cases
>> of extensibility are doing so with good intentions. I think this is
>> just an unusual case where our normal ways of engineering
>> extensibility are way more dangerous than usual. (*)
>> 
> Of course this pressure exists. Are you arguing that a vocabulary
> registry for a signaling protocol which requires a standards action
> to modify is necessarily less resistant to this pressure than the
> standards process itself? If so, can you explain the mechanism by
> which that is the case? Because they seem like exactly the same thing
> to me.

I do think the IANA route is necessarily more risky yes. I do not
claim that there exists an acceptably risky non-IANA approach. The
reason is that if there is an IANA registry for extensibility then
that a) allows squatting and b) constrains protocol design, e.g.
to protocols that allow for a large enough codepoint-space. To try
be more concrete: without an IANA registry one could design a protocol
with one octet of space for some features and one could ensure that
all bits have defined, useful semantics. It would then be possible
to ensure that extending the protocol would generate backwards
compatibility issues. I am not saying that that would be a good
design or a good outcome, but I do think that any IANA based scheme
for extensibility is, in this case, necessarily more risky.

> 
>> any IANA-based scheme would also allow for squatting on
>> codepoints, which we know can become a fait-accompli.
> 
> How is squatting on codepoints not equivalent to the abuse of widely
> deployed protocols and implicit behaviors thereof?

Squatting is easier. And formalising the recognition of
squatted codepoints is also easier.

> 
>> I don't see any way in which IETF/IANA processes could resist the
>> pressure to provide such "policy" support.
> 
> When a registry is requires a standards action to add to, how is this
> statement not equivalent to "The IETF standards process is incapable
> of resisting the pressure to provide such policy support"? This seems
> quite pessimistic, even to me.

See above.

Maybe this explanation might help too: we create IANA registries for
good reasons, one primary one being that those make it easier to
extend protocols. For protocols where we do not want extensions to be
easy, we ought only very carefully create IANA registries.

Cheers,
S.

> 
>> I also cannot think of a non-IANA extensibility mechanism that
>> could work here and not have the privacy downsides.
> 
> I at least fully agree with you that the IANA-managed extensibility
> is as dangerous as or less dangerous than non-IANA managed
> extensibility. So at least we have that. :)
> 
> Thanks, cheers,
> 
> Brian
> 
>> And lastly, there is a significant difference here between
>> existing non-standard methods for injecting the above kinds of
>> information and a world in which we have standardised such
>> extensibility. The status quo may allow for such injection but the
>> full horror of the worst abuse-cases here would require that the
>> abuse-case information flow from end-to-end unimpeded (or almost
>> end-to-end) so reliably abusing that kind of information does I
>> think require a standard.
>> 
>> Hopefully that's clearer, (it's definitely longer;-) and again,
>> I'd really welcome crisper and better text to describe these issues
>> as I'm sure it's a discussion that will recur at other times and
>> places.
>> 
>> Cheers, S.
>> 
>> (*) The "usual" dangers of extensibility are I guess complexity
>> and loss of interoperability, exemplified in the current debate
>> about TLS ciphersuite structure and TLS version intolerance.
>> 
>>> 
>>> thanks,
>>> 
>>> Ted
>>> 
>> 
>> _______________________________________________ Spud mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/spud
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 6 Aug 2016 13:38:36 +0100

Hi Kyle,

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

> privacy at the routing layers on the public internet is hopeless.

FWIW, I never agree that privacy is hopeless.

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

IOW - it is not hopeless and the sky is not falling:-)

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.

> addresses to under-18's. Enforce it at the ISPs and you're done.

Yes, that and many other abominations could theoretically be attempted.

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.

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

Cheers,
S.

---

From: Kyle Rose <[email-masked]>
Date: Wed, 10 Aug 2016 08:41:33 -0400

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

And again for me. :-)

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

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

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

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

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