Subject: [Spud] Detecting and Defeating TCP/IP Hypercookie Attacks

From: Brian Trammell <[email-masked]>
Date: Fri, 29 Jul 2016 14:33:39 +0200

Greetings, all,

During the PLUS BoF last week, concern was expressed that a generic signaling mechanism such as proposed opened two new attack surfaces:

(1) A method for endpoints to allow path elements to add non-integrity protected signals presents a surface for metadata injection attacks, where an entity who can place devices on a user's access network and has information about the user's identity could exfiltrate that information to third parties. For purposes of giving it a name, let's call this a hypercookie injection attack ("hyper" since it exists in a space completely inaccessible to the application).

(2) Even if path elements are not allowed to say anything, a mechanism to allow endpoints to add integrity-protected signals to their traffic presents a surface for coercion attacks. An access provider can force a user to tag traffic with their user ID or some other token (a signed assertion that an advertisement has been viewed to the end, or maybe even just straight-up bitcoins) in order to get "better" connectivity, or even any connectivity at all. A more classically Orwellian dystopian variant of this attack has a government requiring citizens to tag all their outgoing traffic with some government-issued identifier. Let's call this a hypercookie coercion attack.

I am less concerned about the surface PLUS presents to these attacks than those who have raised the concerns in the BoF and on the mailing list, because the current Internet architecture is already quite vulnerable to them. As I said during my presentation last Thursday, Ted Hardie and I sat down to think about this at lunch a couple of months ago, and found six ways one could execute hypercookie injection or coercion today before our pizza showed up.

I sat down a little longer to write these up. I found five more, without even considering trivial out-of-band metadata leaks or steganographic side channels. https://tools.ietf.org/html/draft-trammell-privsec-defeating-tcpip-meta-00 is the result. The conclusion: these attacks are trivially easy to execute today by exploiting the gap between valid TCP traffic and what will be ignored by TCP-indifferent devices and endpoints, as well as all those juicy bits IPv6 gives you. Unless we're willing to rely on the widespread, altruistic deployment of stateful TCP firewalls to reject traffic (I think we can use our experience with BCP38 as guidance as to how well *that* will work, and in any case I think it would be kind of rich for me of all people to recommend throwing more TCP-meddling middleboxes into the mix) the only way I can see out is to add integrity protection to all transport and network-layer headers, as well as confidentiality protection to those headers the path does not need to see.

This is, of course, the whole point of PLUS. We can and should have a discussion of what the endpoints should be able to say, and what the endpoints should be able to let the path say. But if we're concerned about this attack, the general approach is AFAICT the only way out.

Cheers,

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Jul 2016 14:23:17 +0100

Hi Brian,

On 29/07/16 13:33, Brian Trammell wrote:
> Greetings, all,
> 
> During the PLUS BoF last week, concern was expressed that a generic
> signaling mechanism such as proposed opened two new attack surfaces:

No necessarily "opened...new" perhaps more "risked making much
more ubiquitous." At the meeting I didn't hear anyone claim these
were new attacks. (I did hear you say they were not new.)

> 
> (1) A method for endpoints to allow path elements to add
> non-integrity protected signals presents a surface for metadata
> injection attacks, where an entity who can place devices on a user's
> access network and has information about the user's identity could
> exfiltrate that information to third parties. For purposes of giving
> it a name, let's call this a hypercookie injection attack ("hyper"
> since it exists in a space completely inaccessible to the
> application).
> 
> (2) Even if path elements are not allowed to say anything, a
> mechanism to allow endpoints to add integrity-protected signals to
> their traffic presents a surface for coercion attacks. An access
> provider can force a user to tag traffic with their user ID or some
> other token (a signed assertion that an advertisement has been viewed
> to the end, or maybe even just straight-up bitcoins) in order to get
> "better" connectivity, or even any connectivity at all. A more
> classically Orwellian dystopian variant of this attack has a
> government requiring citizens to tag all their outgoing traffic with
> some government-issued identifier. Let's call this a hypercookie
> coercion attack.
> 
> I am less concerned about the surface PLUS presents to these attacks
> than those who have raised the concerns in the BoF and on the mailing
> list, because the current Internet architecture is already quite
> vulnerable to them. As I said during my presentation last Thursday,
> Ted Hardie and I sat down to think about this at lunch a couple of
> months ago, and found six ways one could execute hypercookie
> injection or coercion today before our pizza showed up.

Wrt injection I can buy that totally. Having read your draft
I don't find enough there to accept your assertion wrt
coercion - ISTM that coercion attacks have not been analysed
yet in your draft.

As a side-note, meta-data doesn't have to be person-specific to
be controversial - "over 18" and anything with similar semantics,
e.g. "member of <this> minority" can very clearly be equally or
more damaging, yet totally non-identifying if the relevant set of
folks is large enough. So I wonder if the "hypercookie" concept
is even the right starting point here. And to the extent that
PLUS could enable and standardise such things, that is, for me,
a major reason to oppose PLUS. (That's a side-note for this
email, but perhaps a quite fundamental thing to consider in the
overall discussion.)

> 
> I sat down a little longer to write these up. I found five more,
> without even considering trivial out-of-band metadata leaks or
> steganographic side channels.
> https://tools.ietf.org/html/draft-trammell-privsec-defeating-tcpip-meta-00
> is the result. The conclusion: these attacks are trivially easy to
> execute today by exploiting the gap between valid TCP traffic and
> what will be ignored by TCP-indifferent devices and endpoints, as
> well as all those juicy bits IPv6 gives you. Unless we're willing to
> rely on the widespread, altruistic deployment of stateful TCP
> firewalls to reject traffic (I think we can use our experience with
> BCP38 as guidance as to how well *that* will work, and in any case I
> think it would be kind of rich for me of all people to recommend
> throwing more TCP-meddling middleboxes into the mix) the only way I
> can see out is to add integrity protection to all transport and
> network-layer headers, as well as confidentiality protection to those
> headers the path does not need to see.

I don't agree. Observatories seem to me like a mitigation that
your draft does not consider. If the attacker here does not want
to be seen to be attacking, then those can be effective. Should
we standardise a method for such abuse, then I think it's quite
possible the attacker may argue that their behaviour is not an
attack as it's just a part of "the standard."

Such a mitigation could be attempted against the attack in 4.1.3
of your draft for example so I disagree with the draft's assertion
that "no user-initiated mitigation is possible" in that case at
least and maybe others.

I think it'd be a fine thing to see further analysis of the attacks
and potential mitigations as your draft develops.

> 
> This is, of course, the whole point of PLUS. We can and should have a
> discussion of what the endpoints should be able to say, and what the
> endpoints should be able to let the path say. But if we're concerned
> about this attack, the general approach is AFAICT the only way out.

I disagree. And I think it was clear that a whole bunch of folks
in the room last week also clearly disagreed.

I believe your "only way out" conclusion isn't logically justified as
the argument seems to ignore the downsides of standardising and thus
legitimising "bad" behaviour including behaviours that your draft
properly calls an attack.

Frankly, I was and remain puzzled by SPUD/PLUS. ISTM that we have
different sets of sensible folks reaching diametrically opposed
conclusions based on the same facts and arguments. Perhaps the tl;dr
in your abstract may be a hint there - I do not think everything
is ruined myself, so maybe one's level of opt/pess-imism affects
one's view of the valid conclusions to reach in this space.

Cheers,
S.

> 
> Cheers,
> 
> Brian
> 
> 
> 
> _______________________________________________ Privsec-program
> mailing list [email-masked] 
> https://www.iab.org/mailman/listinfo/privsec-program
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 29 Jul 2016 16:48:33 +0200

Hi Stephen,

I believe that what you think PLUS is, is not what we propose. Maybe we did not make a great job so far to define PLUS narrowly enough but we believe the actual protocol specification work should be done in a wg to ensure that a broad community can participate, and all concern, including privacy concerns, can be addressed.

The point of draft-trammell-privsec-defeating-tcpip-meta is to further explain that the things you describe as risks are nothing new. And by new, we mean they are even standard-conform; because this is the main point of your concern if I understand you correctly, right? 

I assume your point is that we propose a protocol that is intended to signal information from middleboxes to the endpoint (amongst other features). I assume this based on the following statement you made:

> Should
> attack as it's just a part of "the standard.“

and 

> And to the extent that
> a major reason to oppose PLUS. 

Otherwise can you please further explain what you mean by „such abuse“ and „such things“?

If the thing you are concerned about in PLUS is, that we propose to standardize ‚option‘ space that explicitly allows middleboxes to add information to a packet, I guess you know that it is possible to define an experimental TCP option (in the ISE stream) without IESG approval that allows the insertion of private information by middleboxes. Even thought TCP options are not intended to be altered by network nodes, there is also no standard that forbids this.

Let me say two things about what we ACTUALLY propose with PLUS:
1) We do NOT propose to add space to add arbitrary information. The semantic of the field must be well-defined in an IESG approved RFC and registered respectively. This will not only make it not-standard conform to use such a field for something different, it also restrict the set of valid values which then could even be checked by later middleboxes on the path, and erased if needed.
2) Further only PLUS provides an additional function that allows to detect any mangling of data/bits that was not intended. This is urgently needed because all the TCP (and higher) layer mangling we see today is the root cause for the problem we have right now.

Further, I would like to say that not all middlebox mangling is automatically bad or an attack. If we don’t provide a standardized way to communicate with middleboxes, it will be even harder to distinguish an attack from something that actually supports the network service provided or even makes the services possible at all. Without standardization there is no control at all. I don’t think we can ignore what’s already happening the Internet any further and providing standardized mechanisms to support the good in-network functions is the only way to improve security for these functions.

> properly calls an attack.

We not at all want to legitimate „bad“ behavior and I really don’t know why you think that what we propose would do so. We propose to standardize a protocol that allows middleboxes to provide information they have been requested for (by the endhost). This information is well define and under IESG approval. Any other use of such a protocol will not be standard-conform and as bad as the misuse we can see today with existing protocols.

Mirja

> Am 29.07.2016 um 15:23 schrieb Stephen Farrell <[email-masked]>:
> 
> 
> Hi Brian,
> 
> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Jul 2016 16:17:19 +0100

Hiya,

On 29/07/16 15:48, Mirja Kühlewind wrote:
> Hi Stephen,
> 
> I believe that what you think PLUS is, is not what we propose. 

I'm pretty sure that's true - and is part of what puzzles me
as I said before.

> Maybe
> we did not make a great job so far to define PLUS narrowly enough but
> we believe the actual protocol specification work should be done in a
> wg to ensure that a broad community can participate, and all concern,
> including privacy concerns, can be addressed.

I get that. Some folks however (and I'm not sure if I'd count myself
amongst them yet or not) fear that any such WG has to end up as very
privacy unfriendly if it remains transport agnostic. From that
perspective, starting a WG would not make sense.

> 
> The point of draft-trammell-privsec-defeating-tcpip-meta is to
> further explain that the things you describe as risks are nothing
> new. And by new, we mean they are even standard-conform; because this
> is the main point of your concern if I understand you correctly,
> right?

No. Brian's draft doesn't touch on the "over 18" type threat at
all as I read it, so I don't accept the idea that the hypercookie
is the right place from which to start to analyse the set of
threats in this space.

And there is IMO a real difference between our current/old set
of protocols allowing bad behaviours vs. us defining a new
protocol to explicitly enable those same bad behaviours. (It could
be that not all of us agree that that is a real difference.)

> 
> I assume your point is that we propose a protocol that is intended to
> signal information from middleboxes to the endpoint (amongst other
> features). I assume this based on the following statement you made:
> 
>> Should we standardise a method for such abuse, then I think it's
>> quite possible the attacker may argue that their behaviour is not
>> an attack as it's just a part of "the standard.“
> 
> and
> 
>> And to the extent that PLUS could enable and standardise such
>> things, that is, for me, a major reason to oppose PLUS.
> 

Sorry I don't get the question. (That is, I'm not clear if I do
or do not agree with your assumptions, which are not clear to me;-)

> 
> If the thing you are concerned about in PLUS is, that we propose to
> standardize ‚option‘ space that explicitly allows middleboxes to add
> information to a packet, I guess you know that it is possible to
> define an experimental TCP option (in the ISE stream) without IESG
> approval that allows the insertion of private information by
> middleboxes. Even thought TCP options are not intended to be altered
> by network nodes, there is also no standard that forbids this.

I am not arguing for a "MINUS" (a TBD acronym that'd be the antithesis
of PLUS:-).

> 
> Let me say two things about what we ACTUALLY propose with PLUS: 1) We
> do NOT propose to add space to add arbitrary information. The
> semantic of the field must be well-defined in an IESG approved RFC
> and registered respectively. 

IMO that is not sufficient to allay my concern about "over 18" and
the like. If we build it (the registry) then they will come (and ask
for or squat on code points with horrible semantics). I can't see
any way to avoid that other than never creating such a registry.

> This will not only make it not-standard
> conform to use such a field for something different, it also restrict
> the set of valid values which then could even be checked by later
> middleboxes on the path, and erased if needed. 

Sure. But I remain convinced that any registry here is too dangerous
and the above doesn't convince me otherwise.

> 2) Further only PLUS
> provides an additional function that allows to detect any mangling of
> data/bits that was not intended. This is urgently needed because all
> the TCP (and higher) layer mangling we see today is the root cause
> for the problem we have right now.

I don't get your point (2) sorry. Can you explain more?

> 
> Further, I would like to say that not all middlebox mangling is
> automatically bad or an attack. 

Of course. And I did not say that. I said that there are some
bad behaviours in this space and we need to worry about us maybe
legitimising those.

> If we don’t provide a standardized
> way to communicate with middleboxes, it will be even harder to
> distinguish an attack from something that actually supports the
> network service provided or even makes the services possible at all.
> Without standardization there is no control at all. I don’t think we
> can ignore what’s already happening the Internet any further and
> providing standardized mechanisms to support the good in-network
> functions is the only way to improve security for these functions.

The above text seems indicative of understandable exasperation but
I don't see how it's very useful for the discussion.

>> the argument seems to ignore the downsides of standardising and
>> thus legitimising "bad" behaviour including behaviours that your
>> draft properly calls an attack.
> 
> We not at all want to legitimate „bad“ behavior and I really don’t
> know why you think that what we propose would do so.

Sigh. I didn't personalise this (I hope! Apologies if I did by
mistake) so I wasn't at all discussing what you or anyone wants or
doesn't want. It is entirely possible to have good motivation for
something that may have quite bad side-effects.

And I still think that the arguments made by proponents of PLUS
are ignoring the downsides. (And I do not mean that the people
making those arguments are ignoring those downsides which would
be a different statement.)

> We propose to
> standardize a protocol that allows middleboxes to provide information
> they have been requested for (by the endhost). This information is
> well define and under IESG approval. Any other use of such a protocol
> will not be standard-conform and as bad as the misuse we can see
> today with existing protocols.

I think that just repeats earlier statements.

S.

>>> During the PLUS BoF last week, concern was expressed that a
>>> generic signaling mechanism such as proposed opened two new
>>> attack surfaces:
>> 
>> No necessarily "opened...new" perhaps more "risked making much more
>> ubiquitous." At the meeting I didn't hear anyone claim these were
>> new attacks. (I did hear you say they were not new.)
>> 
>>> 
>>> injection attacks, where an entity who can place devices on a
>>> user's access network and has information about the user's
>>> identity could exfiltrate that information to third parties. For
>>> purposes of giving it a name, let's call this a hypercookie
>>> injection attack ("hyper" since it exists in a space completely
>>> inaccessible to the application).
>>> 
>>> mechanism to allow endpoints to add integrity-protected signals
>>> to their traffic presents a surface for coercion attacks. An
>>> access provider can force a user to tag traffic with their user
>>> ID or some other token (a signed assertion that an advertisement
>>> has been viewed to the end, or maybe even just straight-up
>>> bitcoins) in order to get "better" connectivity, or even any
>>> connectivity at all. A more classically Orwellian dystopian
>>> variant of this attack has a government requiring citizens to tag
>>> all their outgoing traffic with some government-issued
>>> identifier. Let's call this a hypercookie coercion attack.
>>> 
>>> I am less concerned about the surface PLUS presents to these
>>> attacks than those who have raised the concerns in the BoF and on
>>> the mailing list, because the current Internet architecture is
>>> already quite vulnerable to them. As I said during my
>>> presentation last Thursday, Ted Hardie and I sat down to think
>>> about this at lunch a couple of months ago, and found six ways
>>> one could execute hypercookie injection or coercion today before
>>> our pizza showed up.
>> 
>> Wrt injection I can buy that totally. Having read your draft I
>> don't find enough there to accept your assertion wrt coercion -
>> ISTM that coercion attacks have not been analysed yet in your
>> draft.
>> 
>> As a side-note, meta-data doesn't have to be person-specific to be
>> controversial - "over 18" and anything with similar semantics, e.g.
>> "member of <this> minority" can very clearly be equally or more
>> damaging, yet totally non-identifying if the relevant set of folks
>> is large enough. So I wonder if the "hypercookie" concept is even
>> the right starting point here. And to the extent that PLUS could
>> enable and standardise such things, that is, for me, a major reason
>> to oppose PLUS. (That's a side-note for this email, but perhaps a
>> quite fundamental thing to consider in the overall discussion.)
>> 
>>> 
>>> execute today by exploiting the gap between valid TCP traffic
>>> and what will be ignored by TCP-indifferent devices and
>>> endpoints, as well as all those juicy bits IPv6 gives you. Unless
>>> we're willing to rely on the widespread, altruistic deployment of
>>> stateful TCP firewalls to reject traffic (I think we can use our
>>> experience with BCP38 as guidance as to how well *that* will
>>> work, and in any case I think it would be kind of rich for me of
>>> all people to recommend throwing more TCP-meddling middleboxes
>>> into the mix) the only way I can see out is to add integrity
>>> protection to all transport and network-layer headers, as well as
>>> confidentiality protection to those headers the path does not
>>> need to see.
>> 
>> I don't agree. Observatories seem to me like a mitigation that your
>> draft does not consider. If the attacker here does not want to be
>> seen to be attacking, then those can be effective. Should we
>> standardise a method for such abuse, then I think it's quite 
>> Such a mitigation could be attempted against the attack in 4.1.3 of
>> your draft for example so I disagree with the draft's assertion 
>> I think it'd be a fine thing to see further analysis of the
>> attacks and potential mitigations as your draft develops.
>> 
>>> 
>>> This is, of course, the whole point of PLUS. We can and should
>>> have a discussion of what the endpoints should be able to say,
>>> and what the endpoints should be able to let the path say. But if
>>> we're concerned about this attack, the general approach is AFAICT
>>> the only way out.
>> 
>> I disagree. And I think it was clear that a whole bunch of folks in
>> the room last week also clearly disagreed.
>> 
>> I believe your "only way out" conclusion isn't logically justified
>> as the argument seems to ignore the downsides of standardising and
>> thus legitimising "bad" behaviour including behaviours that your
>> draft properly calls an attack.
>> 
>> conclusions based on the same facts and arguments. Perhaps the
>> tl;dr in your abstract may be a hint there - I do not think
>> everything is ruined myself, so maybe one's level of opt/pess-imism
>> affects one's view of the valid conclusions to reach in this
>> space.
>> 
>> Cheers, S.
>> 
>>> 
>>> Cheers,
>>> 
>>> Brian
>>> 
>>> 
>>> 
>> _______________________________________________ Spud mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/spud
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 29 Jul 2016 08:49:46 -0700

> I am less concerned about the surface PLUS presents to these attacks than those who have raised the concerns in the BoF and on the mailing list, because the current Internet architecture is already…
Brian,

I think there is a significant practical difference between the
vulnerability of hypercookie injection in TCP/IP and what would be
present in PLUS. In order to enforce a hypercookie injection in TCP
one would need to change the TCP stack which typically necessitates a
kernel change. In the PLUS world one would only need changes in the
particular applications of interest, this is is a much easier task for
the attacker.  Now instead of having to deal with large OS vendors
that vigorously defend privacy (e.g. Apple vs. FBI), authorities can
go after much smaller players forcing them to either comply or cease
operations. Putting control of information solely in the users hands
is not necessarily a good thing.

Tom

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 29 Jul 2016 17:54:51 +0200

Hi Stephen,

I see registries as a needed and valuable part of our standardization process. People ignoring registries as well as things that are explicitly specified in a standards document is a different problem. 

> I don't get your point (2) sorry. Can you explain more?

We explained this in the BoF and I believe I made this point very clear in my last mail that I replied to Kyle. But let me state this bit again, because it’s important.

Today, there are a large amount of bits a middlebox can mangle with (as described in draft-trammell-privsec-defeating-tcpip-meta which is not even exhaustive). Most of the described ways to insert information into a packet are not detectable, at least most of the ways described for TCP because all information is in cleartext and the receiver does not know what the sender has originally sent while the mangled information still allows proper operation.

What we propose is to
a) encrypt all bits in the transport/TCP header,
b) provide less bits in a PLUS header, that have been carefully evaluated towards risks that we know today (but didn’t know when we designed TCP), and
c) a MAC that hashes all information provided in the PLUS header to be able to detect mangling by the receiver (which can inform then the sender using an encrypted channel). This also means that the endpoint has the choice to not use PLUS (or any PLUS information fields) if mangling is detected.

All these points together, especially point c, makes the situation compared to what we have today better and not worse!

Mirja

> Am 29.07.2016 um 17:17 schrieb Stephen Farrell <[email-masked]>:
> 
> 
> Hiya,
>

---

From: Brian Trammell <[email-masked]>
Date: Fri, 29 Jul 2016 18:22:55 +0200

hi Stephen,

> were new attacks. (I did hear you say they were not new.)

Point; shall we say "may widen two existing"? (Of course, I disagree that PLUS does widen this surface, otherwise I could not in good conscience work on it. I am afraid we simply have to agree to disagree here, though.)

> coercion - ISTM that coercion attacks have not been analysed

Agreed that the analysis isn't where I'd like it to be yet. There are two major reasons for this. One, this draft is focused on in-band abuse of TCP and IP features (which seemed a good place to start) and it's not clear to me that the real threat of coercion lies at this layer at all: coercion attacks seem a lot easier to implement with out of band techniques at the application layer. Second, with respect to the threat at this layer, it seems that coercion attackers would want to be less detectable, which expands the space of abuse to include low-frequency temporal domain side channels and other quasi-in-band sorts of things.

Coercion is at its heart a layer 9 attack, though, and a good analysis of it that takes this into account would make the draft much better. Happy to accept text on this. Need to get the source into a public GitHub repo to send PRs against, first.

> folks is large enough.

Of course; this is an orthogonal question, though. Here we're considering how many bits you can inject or leak. How many bits you need is a question of how large the space of signals is. If what you're concerned about is linkage on a very small number of bits, though, then everything is even more ruined than we think.

<snip>

>> ... the only way I
> your draft does not consider.

Good point. We should add large-scale Internet observatories to the list of general mitigation approaches (Yay! more measurement to do!). This scales a bit better than firewalls everywhere, but still requires you to throw a lot of power and cooling at the problem if you're going to get enough scale to make the attacks too dangerous to execute.

> If the attacker here does not want
> we standardise a method for such abuse,

... noting that one of the points of this draft is to make it clear that we *have already standardized* at least eleven methods for such abuse with the publication of RFCs 791, 3315, 4291, 6437, 6864, and 6994, among others. These standards don't condone the abuse they enable, but by having MUST NOT send / MUST ignore language, which remains good engineering practice for interoperability, they *do* enable it, and in terms of how much evil the abuse can result in, I don't see that there's really any practical difference between the condoning and enabling.

Methods for encrypting transport headers, whether specific to a single transport protocol (QUIC) or generic (PLUS), would, however, make injection impossible, not just somewhat-mitigatable.

> then I think it's quite

Whether an observatory counts as "user-initiated mitigation" or not is a semantic quibble. Fine.

> and potential mitigations as your draft develops.

An open invitation to all: text appreciated. :) One thing I do want to do is some measurement to see on how many paths these work as advertised.

> I disagree.

Again, agreeing to disagree.

But I think we also have a specific misunderstanding here: the point I wanted make *here* was not "you need PLUS". (I think you do, but that's a separate question.) The "general approach" I referred to (sorry for not being more precise) is: "you *at the very least* need cryptographic integrity protection of transport headers, with confidentiality protection for things the path doesn't need to see".

We can have honest disagreements about what the path needs to see and doesn't, and we should do engineering analysis of the cost-risk-benefit tradeoffs in order to resolve those disagreements.

> one's view of the valid conclusions to reach in this space.

I suspect I've spent a bit too much time staring at how TCP breaks over my career, which is the source of my pessimism, on this particular topic, at least.

One purpose of the draft in its present state is that I realized during the PLUS BoF that others may be making overly optimistic assumptions about what the transport layer does and does not do as defined, and to make sure that everyone who cares to read the draft has a shared understanding of how TCP breaks, so they can make their own conclusions about their own pessimism. I do hope that it can evolve into a generalized guide to breaking brokenness for this particular set of attacks, though.

Thanks, cheers,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Fri, 29 Jul 2016 18:29:32 +0200

Hi, Tom,

> On 29 Jul 2016, at 17:49, Tom Herbert <[email-masked]> wrote:
> 
> kernel change.

Nope. I don't need to touch the endpoints at all for an injection attack. I just need one middlebox near the source to rewrite packets, and (possibly) another one downstream to pick up the signals. (Okay, I might need to hack the kernel on my middleboxes. But I get to do that. They're mine. :) )

Some of these techniques work without kernel changes for coercion attacks, too ("Use this DHCPv6 server to access the network while in the territory of Oceania"). Others (ISN side channels) would require kernel changes. (Exercise for exceptionally paranoid readers: demonstrate that no shipping closed-source consumer stack uses initial sequence numbers and legacy IP fragment identifiers as a side channel to expose metadata to the path.)

The whole point of the attacks as outlined is that the side channel is either undetected by the destination, or that the malformed packets are passed by the path and dropped by the destination.

Cheers,

Brian

> In the PLUS world one would only need changes in the

---

From: Tom Herbert <[email-masked]>
Date: Fri, 29 Jul 2016 10:12:48 -0700

> Nope. I don't need to touch the endpoints at all for an injection attack. I just need one middlebox near the source to rewrite packets, and (possibly) another one downstream to pick up the signals.…
Except that middelboxes presumably do not have access to the encrypted
data so the amount of information they can derive from the packet is
limited. The problem is when the application or user is being coerced
and there is a readily available mechanism that facilitates that. For
example, it seems very possible that a rich signaling mechanism
implemented by the user could be used to enforce a backdoor to
encryption.

Tom

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Jul 2016 20:37:04 +0100

Hiya,

On 29/07/16 16:54, Mirja Kühlewind wrote:
> Hi Stephen,
> 
> I see registries as a needed and valuable part of our standardization
> process. People ignoring registries as well as things that are
> explicitly specified in a standards document is a different problem.

Registries can be a useful way to support extensibility. They can
also be a nuisance that allow for the promulgation of crazy ideas.
And probably lots in between and all at once;-)

None of the generalities above help in this specific case where I
remain convinced that any extensible-generic-PLUS is liable to be
highly dangerous. (And I'm unsure if a non-extensible-PLUS can be
usefully transport independent.)

>>> 2) Further only PLUS provides an additional function that allows
>>> to detect any mangling of data/bits that was not intended. This
>>> is urgently needed because all the TCP (and higher) layer
>>> mangling we see today is the root cause for the problem we have
>>> right now.
>> 
> We explained this in the BoF and I believe I made this point very
> clear in my last mail that I replied to Kyle. But let me state this
> bit again, because it’s important.
> 
> Today, there are a large amount of bits a middlebox can mangle with
> (as described in draft-trammell-privsec-defeating-tcpip-meta which is
> not even exhaustive). Most of the described ways to insert
> information into a packet are not detectable, at least most of the
> ways described for TCP because all information is in cleartext and
> the receiver does not know what the sender has originally sent while
> the mangled information still allows proper operation.

The above is clear, thanks. And is what I got from the BoF too.

> What we propose is to a) encrypt all bits in the transport/TCP
> header, 

Well, no, PLUS is not a proposal to do that iiuc - PLUS is a proposal
to expose some information when such encryption is being done as
defined by some other specification which is not PLUS. If my take
there is wrong, I'd appreciate being corrected.

I would have far less of an issue if e.g. QUIC or other transports
defined in a transport-specific and non-extensible manner how the
few bits of information that might be desirable for the path can be
outside the confidentiality envelope.

I can totally see how some architectural guidance and examples of
the sometimes-subtle threats caused by exposing information were to
be developed. PLUS however seems to be proposing to go beyond that
and to define PDUs, which I think I'm nearly convinced is a bad plan
and a path down which it may be better to not start.

> b) provide less bits in a PLUS header, that have been
> carefully evaluated towards risks that we know today (but didn’t know
> when we designed TCP), and c) a MAC that hashes all information
> provided in the PLUS header to be able to detect mangling by the
> receiver (which can inform then the sender using an encrypted
> channel). This also means that the endpoint has the choice to not use
> PLUS (or any PLUS information fields) if mangling is detected.
> 
> All these points together, especially point c, makes the situation
> compared to what we have today better and not worse!

I get that that's the argument for PLUS. I remain unconvinced by
that argument for the reasons stated earlier.

Cheers,
S.

>> I'm pretty sure that's true - and is part of what puzzles me as I
>> said before.
>> 
>>> Maybe we did not make a great job so far to define PLUS narrowly
>>> enough but we believe the actual protocol specification work
>>> should be done in a wg to ensure that a broad community can
>>> participate, and all concern, including privacy concerns, can be
>>> addressed.
>> 
>> I get that. Some folks however (and I'm not sure if I'd count
>> myself amongst them yet or not) fear that any such WG has to end up
>> as very privacy unfriendly if it remains transport agnostic. From
>> that perspective, starting a WG would not make sense.
>> 
>>> 
>>> further explain that the things you describe as risks are
>>> nothing new. And by new, we mean they are even standard-conform;
>>> because this is the main point of your concern if I understand
>>> you correctly, right?
>> 
>> No. Brian's draft doesn't touch on the "over 18" type threat at all
>> as I read it, so I don't accept the idea that the hypercookie is
>> the right place from which to start to analyse the set of threats
>> in this space.
>> 
>> And there is IMO a real difference between our current/old set of
>> protocols allowing bad behaviours vs. us defining a new protocol to
>> explicitly enable those same bad behaviours. (It could be that not
>> all of us agree that that is a real difference.)
>> 
>>> 
>>> I assume your point is that we propose a protocol that is
>>> intended to signal information from middleboxes to the endpoint
>>> (amongst other features). I assume this based on the following
>>> statement you made:
>>> 
>>>> Should we standardise a method for such abuse, then I think
>>>> it's quite possible the attacker may argue that their behaviour
>>>> is not an attack as it's just a part of "the standard.“
>>> 
>>> and
>>> 
>> Sorry I don't get the question. (That is, I'm not clear if I do or
>> do not agree with your assumptions, which are not clear to me;-)
>> 
>>> 
>>> If the thing you are concerned about in PLUS is, that we propose
>>> to standardize ‚option‘ space that explicitly allows middleboxes
>>> to add information to a packet, I guess you know that it is
>>> possible to define an experimental TCP option (in the ISE stream)
>>> without IESG approval that allows the insertion of private
>>> information by middleboxes. Even thought TCP options are not
>>> intended to be altered by network nodes, there is also no
>>> standard that forbids this.
>> 
>> I am not arguing for a "MINUS" (a TBD acronym that'd be the
>> antithesis of PLUS:-).
>> 
>>> 
>>> 1) We do NOT propose to add space to add arbitrary information.
>>> The semantic of the field must be well-defined in an IESG
>>> approved RFC and registered respectively.
>> 
>> the like. If we build it (the registry) then they will come (and
>> ask for or squat on code points with horrible semantics). I can't
>> see any way to avoid that other than never creating such a
>> registry.
>> 
>>> This will not only make it not-standard conform to use such a
>>> field for something different, it also restrict the set of valid
>>> values which then could even be checked by later middleboxes on
>>> the path, and erased if needed.
>> 
>> Sure. But I remain convinced that any registry here is too
>> dangerous and the above doesn't convince me otherwise.
>> 
>>> 2) Further only PLUS provides an additional function that allows
>>> to detect any mangling of data/bits that was not intended. This
>>> is urgently needed because all the TCP (and higher) layer
>>> mangling we see today is the root cause for the problem we have
>>> right now.
>> 
>> Of course. And I did not say that. I said that there are some bad
>> behaviours in this space and we need to worry about us maybe 
>> legitimising those.
>> 
>>> If we don’t provide a standardized way to communicate with
>>> middleboxes, it will be even harder to distinguish an attack from
>>> something that actually supports the network service provided or
>>> even makes the services possible at all. Without standardization
>>> there is no control at all. I don’t think we can ignore what’s
>>> already happening the Internet any further and providing
>>> standardized mechanisms to support the good in-network functions
>>> is the only way to improve security for these functions.
>> 
>>>> the argument seems to ignore the downsides of standardising
>>>> and thus legitimising "bad" behaviour including behaviours that
>>>> your draft properly calls an attack.
>>> 
>>> We not at all want to legitimate „bad“ behavior and I really
>>> don’t know why you think that what we propose would do so.
>> 
>> And I still think that the arguments made by proponents of PLUS are
>> ignoring the downsides. (And I do not mean that the people making
>> those arguments are ignoring those downsides which would be a
>> different statement.)
>> 
>>> We propose to standardize a protocol that allows middleboxes to
>>> provide information they have been requested for (by the
>>> endhost). This information is well define and under IESG
>>> approval. Any other use of such a protocol will not be
>>> standard-conform and as bad as the misuse we can see today with
>>> existing protocols.
>> 
>>>> more ubiquitous." At the meeting I didn't hear anyone claim
>>>> these were new attacks. (I did hear you say they were not
>>>> new.)
>>>> 
>>>>> 
>>>>> non-integrity protected signals presents a surface for
>>>>> metadata injection attacks, where an entity who can place
>>>>> devices on a user's access network and has information about
>>>>> the user's identity could exfiltrate that information to
>>>>> third parties. For purposes of giving it a name, let's call
>>>>> this a hypercookie injection attack ("hyper" since it exists
>>>>> in a space completely inaccessible to the application).
>>>>> 
>>>>>  mechanism to allow endpoints to add integrity-protected
>>>>> signals to their traffic presents a surface for coercion
>>>>> attacks. An access provider can force a user to tag traffic
>>>>> with their user ID or some other token (a signed assertion
>>>>> that an advertisement has been viewed to the end, or maybe
>>>>> even just straight-up bitcoins) in order to get "better"
>>>>> connectivity, or even any connectivity at all. A more
>>>>> government requiring citizens to tag all their outgoing
>>>>> traffic with some government-issued identifier. Let's call
>>>>> this a hypercookie coercion attack.
>>>>> 
>>>>> attacks than those who have raised the concerns in the BoF
>>>>> and on the mailing list, because the current Internet
>>>>> architecture is already quite vulnerable to them. As I said
>>>>> during my presentation last Thursday, Ted Hardie and I sat
>>>>> down to think about this at lunch a couple of months ago, and
>>>>> found six ways one could execute hypercookie injection or
>>>>> coercion today before our pizza showed up.
>>>> 
>>>> don't find enough there to accept your assertion wrt coercion
>>>> - ISTM that coercion attacks have not been analysed yet in
>>>> your draft.
>>>> 
>>>> be controversial - "over 18" and anything with similar
>>>> semantics, e.g. "member of <this> minority" can very clearly be
>>>> equally or more damaging, yet totally non-identifying if the
>>>> relevant set of folks is large enough. So I wonder if the
>>>> "hypercookie" concept is even the right starting point here.
>>>> things, that is, for me, a major reason to oppose PLUS. (That's
>>>> a side-note for this email, but perhaps a quite fundamental
>>>> thing to consider in the overall discussion.)
>>>> 
>>>>> 
>>>>> I sat down a little longer to write these up. I found five
>>>>> more, without even considering trivial out-of-band metadata
>>>>> leaks or steganographic side channels. 
>>>>> execute today by exploiting the gap between valid TCP
>>>>> traffic and what will be ignored by TCP-indifferent devices
>>>>> and endpoints, as well as all those juicy bits IPv6 gives
>>>>> you. Unless we're willing to rely on the widespread,
>>>>> altruistic deployment of stateful TCP firewalls to reject
>>>>> traffic (I think we can use our experience with BCP38 as
>>>>> guidance as to how well *that* will work, and in any case I
>>>>> think it would be kind of rich for me of all people to
>>>>> recommend throwing more TCP-meddling middleboxes into the
>>>>> mix) the only way I can see out is to add integrity 
>>>>> protection to all transport and network-layer headers, as
>>>>> well as confidentiality protection to those headers the path
>>>>> does not need to see.
>>>> 
>>>> your draft does not consider. If the attacker here does not
>>>> want to be seen to be attacking, then those can be effective.
>>>> Should we standardise a method for such abuse, then I think
>>>> it's quite possible the attacker may argue that their behaviour
>>>> is not an attack as it's just a part of "the standard."
>>>> 
>>>> Such a mitigation could be attempted against the attack in
>>>> 4.1.3 of your draft for example so I disagree with the draft's
>>>> assertion that "no user-initiated mitigation is possible" in
>>>> that case at least and maybe others.
>>>> 
>>>>> This is, of course, the whole point of PLUS. We can and
>>>>> should have a discussion of what the endpoints should be able
>>>>> to say, and what the endpoints should be able to let the path
>>>>> say. But if we're concerned about this attack, the general
>>>>> approach is AFAICT the only way out.
>>>> 
>>>> I disagree. And I think it was clear that a whole bunch of
>>>> folks in the room last week also clearly disagreed.
>>>> 
>>>> I believe your "only way out" conclusion isn't logically
>>>> justified as the argument seems to ignore the downsides of
>>>> standardising and thus legitimising "bad" behaviour including
>>>> behaviours that your draft properly calls an attack.
>>>> 
>>>> Frankly, I was and remain puzzled by SPUD/PLUS. ISTM that we
>>>> have different sets of sensible folks reaching diametrically
>>>> opposed conclusions based on the same facts and arguments.
>>>> Perhaps the tl;dr in your abstract may be a hint there - I do
>>>> not think everything is ruined myself, so maybe one's level of
>>>> opt/pess-imism affects one's view of the valid conclusions to
>>>> reach in this space.
>>>> 
>>>> Cheers, S.
>>>> 
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Brian
>>>>> 
>>>>> 
>>>>> 
>>>>> Privsec-program mailing list [email-masked] 
>>>> _______________________________________________ Spud mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/spud
>>> 
>>

---

From: Stephan Neuhaus <[email-masked]>
Date: Fri, 29 Jul 2016 21:52:18 +0200

> implemented by the user could be used to enforce a backdoor to

Now I'm confused. I thought that the situation that Brian was talking
about is middleboxes fiddling with the packet headers, which are in
plaintext, and not with the packet's payload which, as you say, may be
encrypted. You seem to be saying that the amount of information that can
be extracted from plaintext transport headers is limited, is that correct?

Brian is also talking about the path; you seem to be talking about the
endpoints, is that correct?

If both these assumptions are correct, then I'd like to make three
points. (If they're both wrong, please stop reading. If one is right and
one is wrong, read only half of what follows.  You choose which half :-) )

First, I do not agree that the amount of information in the transport
headers is limited, which I assume means "of limited value". It's
classic metadata and should be protected, if possible. That transport
header is seen by many more boxes than the plaintext of the encrypted
payload and thus the probability of someone siphoning it off are that
much larger, precisely because it is valuable.

Second, I'm not sure in what way "a rich signaling mechanism
implemented by the user could be used to enforce a backdoor to
encryption" or rather, I'm not sure how that is a problem enabled
specifically by PLUS. If the "user" (which I understand to be an
application running on top of a networking stack) wants to "backdoor its
encryption" (i.e., leak key material), it can already do so today. For
example, a suitably modified TLS library could stash the master secret
at the end of a TLS message (may work with many applications, even
without an equally compromised TLS library on the other end). Or it
could silently always use DUAL_EC_DRBG (always works). Or ... Many of
these would go undetected for a long time. The upshot is: once your
endpoint is compromised, all bets are off anyway.

And finally, have the impression that you think that PLUS is going to be
this gigantic free-for-all, where every Joe, Dick, and Harry can
annotate a packet in any way they please. If I understood the PLUS
proponents correctly, this will not be the case. PLUS fields will be
limited in number, space, and semantics, and they will (for the most
part) be integrity-protected so that nothing on the path can fiddle with
them without anyone noticing.

To summarise: 1) If your endpoint is compromised, you're screwed anyway.
2) The total amount space that's available for undetected fiddling by a
middlebox will perhaps not be zero, but it will be less than it is today.

Fun,

Stephan

[Full disclosure: I'm working with Brian and Mirja on the MAMI project.]

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Jul 2016 21:17:05 +0100

Hiya,

On 29/07/16 17:22, Brian Trammell wrote:
> Point; shall we say "may widen two existing"? (Of course, I disagree
> that PLUS does widen this surface, otherwise I could not in good
> conscience work on it. I am afraid we simply have to agree to
> disagree here, though.)

Well, PLUS would have to minimally extend the attack surface at
least in an xkcd-one-more-standard manner. One could still in good
conscience argue for that though if one thought that the existence
of the new, standard method for injecting meta-data meant that the
overall amount of privacy unfriendly behaviour would be reduced.
While that's an argument that could be made, I'd not be convinced
by it unless we had evidence that standardising something like PLUS
would result in just that changed behaviour, and I can't see that
that's possible.

> Agreed that the analysis isn't where I'd like it to be yet. There are
> two major reasons for this. One, this draft is focused on in-band
> abuse of TCP and IP features (which seemed a good place to start) and
> it's not clear to me that the real threat of coercion lies at this
> layer at all: coercion attacks seem a lot easier to implement with
> out of band techniques at the application layer. 

Hmm, not sure myself. Worth pondering and (hey, your fav... :-)
doing some measurement.

> Second, with respect
> to the threat at this layer, it seems that coercion attackers would
> want to be less detectable, which expands the space of abuse to
> include low-frequency temporal domain side channels and other
> quasi-in-band sorts of things.

There's a lot packed into the above sentence that I think may be
usefully unpicked in future revisions of your draft. I'm not sure
I agree about wanting to be less detectable - the common usage of
outrageous terms and conditions is both detectable and fits here.

> Coercion is at its heart a layer 9 attack, though, and a good
> analysis of it that takes this into account would make the draft much
> better. Happy to accept text on this. Need to get the source into a
> public GitHub repo to send PRs against, first.
> 
>> is large enough.
> Of course; this is an orthogonal question, though. 

Yes and no. The question is a side-note in my mail but IMO crucial to
the questions about PLUS overall.

> Here we're
> considering how many bits you can inject or leak. How many bits you
> need is a question of how large the space of signals is. If what
> you're concerned about is linkage on a very small number of bits,
> though, then everything is even more ruined than we think.

Well, I didn't agree that ruined is a good descriptor though:-)

My point is that the entropy of the signal ought not be the only
consideration - there have historically been some societies where
just one bit (in-group/out-group) would have been sufficient to
cause an awful lot of damage. I think we really do need to think
hard about changes to the transport layer that might enable such
discrimination at that layer and at such scale.

> 
> <snip>
> 
>>> ... the only way I can see out is to add integrity protection to
>>> all transport and network-layer headers, as well as
>> draft does not consider.
> Good point. We should add large-scale Internet observatories to the
> list of general mitigation approaches (Yay! more measurement to do!).
> This scales a bit better than firewalls everywhere, but still
> requires you to throw a lot of power and cooling at the problem if
> you're going to get enough scale to make the attacks too dangerous to
> execute.

That's not clear to me at all. Some observatory functions may only
require putting up a server that says what it sees, or even better
building such features into loads of other servers that have a day
job. Things like [1] and [2] aren't necessarily that expensive and
can play their part here I think and even though observatory might
not be the right term for those, such things can be part of the
overall set of mitigations here.

   [1] http://ipv6-test.com/ (no working https, sorry:-)
   [2] https://dnsviz.net/

But yes, other observatories may be more expensive.

> 
>> If the attacker here does not want to be seen to be attacking, then
>> those can be effective. Should we standardise a method for such
>> abuse,
> 
> ... noting that one of the points of this draft is to make it clear
> that we *have already standardized* at least eleven methods for such
> abuse with the publication of RFCs 791, 3315, 4291, 6437, 6864, and
> 6994, among others. 

I would not use the above phrasing. I don't believe that the IETF
intended to standardise the abuse-cases in all of those. I'm not
even sure if the folks concerned thought of those abuses before it
was too late. If there are cases where we did, documenting that would
also be a fine thing for your draft to do, to help us understand
how to not make those mistakes again.

> These standards don't condone the abuse they
> enable, but by having MUST NOT send / MUST ignore language, which
> remains good engineering practice for interoperability, they *do*
> enable it, 

Right. Making that point in your draft (or wherever), may be quite
valuable. (Maybe there's a statement or two to add to 3552bis on
this topic as well?)

> and in terms of how much evil the abuse can result in, I
> don't see that there's really any practical difference between the
> condoning and enabling.

I do, as previously noted.

> 
> Methods for encrypting transport headers, whether specific to a
> single transport protocol (QUIC) or generic (PLUS), would, however,
> make injection impossible, not just somewhat-mitigatable.

So a different question: what other protocol that is not QUIC is one
where PLUS would be beneficial? And wouldn't the existence of PLUS
and it's use with any protocol that didn't encrypt as much as QUIC
represent a clear standardisation and extension of the bad features
here? (I guess I may be partly asking if the SPUD/PLUS idea has been
OBE here.)

> 
>> then I think it's quite possible the attacker may argue that their
>> behaviour is not an attack as it's just a part of "the standard."
>> 

Some observatories are, some are not. One for 4.1.3 could well be
user-initiated and cheap. That may well not be the case for others
that could be useful against other of the attacks in your draft.

> An open invitation to all: text appreciated. :) One thing I do want
> to do is some measurement to see on how many paths these work as
> advertised.
> 
> But I think we also have a specific misunderstanding here: the point
> I wanted make *here* was not "you need PLUS". (I think you do, but
> that's a separate question.) The "general approach" I referred to
> (sorry for not being more precise) is: "you *at the very least* need
> cryptographic integrity protection of transport headers, with
> confidentiality protection for things the path doesn't need to see".
> 
> We can have honest disagreements about what the path needs to see and
> doesn't, and we should do engineering analysis of the
> cost-risk-benefit tradeoffs in order to resolve those disagreements.

Yes, discussions on the above can be had (and I'm sure you've been
having 'em happily without me for quite a while:-).

I don't however see how those discussions lead to a conclusion that
there is value in an an attempt to provide an extensible and transport-
independent solution. That last seems like maybe the least desirable
approach one could take here as I think it leads to solutions that
are most open to additional abuse.

> I suspect I've spent a bit too much time staring at how TCP breaks
> over my career, which is the source of my pessimism, on this
> particular topic, at least.

Sure. The question is whether or not that's part of the reason we
see folks coming to such different conclusions. I don't claim to
know the answer btw;-)

> 
> One purpose of the draft in its present state is that I realized
> during the PLUS BoF that others may be making overly optimistic
> assumptions about what the transport layer does and does not do as
> defined, and to make sure that everyone who cares to read the draft
> has a shared understanding of how TCP breaks, so they can make their
> own conclusions about their own pessimism. I do hope that it can
> evolve into a generalized guide to breaking brokenness for this
> particular set of attacks, though.

Yeah, I think the evolution of your draft may be of value independent
of PLUS.

S.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 29 Jul 2016 13:18:30 -0700

On Fri, Jul 29, 2016 at 12:37 PM, Stephen Farrell <[email-masked]
> wrote:

> usefully transport independent.)
So, it's not clear to me exactly what you mean by "transport independent"
here, so let me drill down a bit.  I think PLUS is proposed for a set of
transports that use the UDP demux (and thanks to Stuart Cheshire for a
useful shorthand for that function).  It expects that those transports will
integrity protect their transport headers and treat as confidential some
aspects of their state exchange (a multiplexing transport, for example,
might decide that the state of the flows being multiplexed should be
confidential).  A PLUS with very limited semantics (start, stop, delay
tolerant, drop tolerant) would likely be broadly applicable to that class
of transports and yet be transport independent (for that specific meaning
of transport).

The folks arguing for this have a set of concerns:

*) Some useful path elements are impaired now, compared to previously.  How
can we safely repair that impairment?  Where safely means:  not restoring
plaintext for inspection nor providing a worse-than-current side channel
for identification.  (I accept that analysing one against "current"
requires understanding ease of attacking the side channel)

*) If there is a new, popular transport protocol, how do we ensure that it
does not end up as the new HTTP, used for a variety of things not because
it is suitable on design fit but because it gets through the network?  To
put this another way, how do we make sure that the new design pattern given
above opens innovation at that transport layer?

While the proponents of PLUS believe that a substrate approach is the most
deployable (because you can redefine things like SRTP to run over PLUS
instead of bare UDP), we care much more that the approach meets those
concerns than the approach be a substrate.  If you want to call it a
"design pattern" and implement it in a couple of candidates from that
design pattern, fine.  You end up describing the thing multiple times
rather than once, but cut and paste is a fine tool.

Does this description make sense to you?  Or are we still a bit at cross
purposes here?

Ted

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Jul 2016 21:40:42 +0100

Hiya,

On 29/07/16 21:18, Ted Hardie wrote:
>>> I see registries as a needed and valuable part of our 
>>> standardization process. People ignoring registries as well as 
>>> things that are explicitly specified in a standards document is a
>>> different problem.
>> 

I guess I meant a future in which PLUS-defined PDUs are used as
meta-data in/with various transport protocols.

> here, so let me drill down a bit.  I think PLUS is proposed for a set
> of transports that use the UDP demux (and thanks to Stuart Cheshire
> for a useful shorthand for that function).  It expects that those
> transports will integrity protect their transport headers and treat
> as confidential some aspects of their state exchange (a multiplexing
> transport, for example, might decide that the state of the flows
> being multiplexed should be confidential).  A PLUS with very limited
> semantics (start, stop, delay tolerant, drop tolerant) would likely
> be broadly applicable to that class of transports and yet be
> transport independent (for that specific meaning of transport).

If plus were limited to only emitting those signals then I'd be far
less concerned. I think that would mean that there is no need for any
extensibility and hence no registry. I do not claim to know if those
and only those signals would be sufficiently useful to be adopted by
transport protocols and implementations thereof.

> *) Some useful path elements are impaired now, compared to 
> previously.

FYI, I find the term "impaired" scarily vague in this context. It could
mean anything from "0.1% less reliable" to "no longer allows me assert
that the person using the machine is over 18." That lack of specificity
and the absence iiuc of public data describing the claimed impairments
damages the argument of the PLUS proponents here.

> How can we safely repair that impairment?

That depends on what is considered impairment and without a shared idea
of that I don't think we can get to an answer.

> Where safely means:  not restoring
> plaintext for inspection nor providing a worse-than-current side 
> channel for identification.  (I accept that analysing one against 
> "current" requires understanding ease of attacking the side channel)
> 
> *) If there is a new, popular transport protocol, how do we ensure 
> that it does not end up as the new HTTP, used for a variety of things
> not because it is suitable on design fit but because it gets through
> the network? 

(Aside: if new transports are as successful as http, then we're making
progress I think:-)

> To put this another way, how do we make sure that the
> new design pattern given above opens innovation at that transport
> layer?
> 
> While the proponents of PLUS believe that a substrate approach is the
> most deployable (because you can redefine things like SRTP to run
> over PLUS instead of bare UDP), we care much more that the approach
> meets those concerns than the approach be a substrate.  If you want
> to call it a "design pattern" and implement it in a couple of
> candidates from that design pattern, fine.  You end up describing the
> thing multiple times rather than once, but cut and paste is a fine
> tool.

I agree with your last there. I actually think cut'n'paste is likely
a better approach here - it means that one can evaluate the essential
signals in each case, whereas the substrate/shim approach requires
that one has that dangerous extensibility. And for what real value?

> 
> Does this description make sense to you?  Or are we still a bit at 
> cross purposes here?

Aside from the vagueness in "impairment" I think I understand it yes.
(And this may be a thing where it's possible to not be talking at
cross purposes and yet still disagree as to whether there ought be
any path forward at all for PLUS.)

Cheers,
S.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 29 Jul 2016 14:14:22 -0700

> damages the argument of the PLUS proponents here.
The specific impairments vary over the type of network, but the class is
"consume more resources than previously".  Resources here can be radio
bandwidth, power from a total radio power budget, delay intolerant queue
slots, state table size, and so on.  Note that these impairments have
implications for the end systems as well, as the hoary example of UDP
heartbeat traffic and NAT state shows.

> Does the class given above help?

> (Aside: if new transports are as successful as http, then we're making
QUIC has that potential, if the race against HTTP/2 tests so far are any
guide.

> I'm not sure that the substrate/shim approach does require dangerous
extensibility; if we limit it to get what's needed, we may avoid the
danger.  And the value is the usual:  common libraries, common APIs, and
common understandings of the threat model.

> any path forward at all for PLUS.)
regards,

Ted

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 Jul 2016 14:22:04 -0700

On 7/29/2016 9:22 AM, Brian Trammell wrote:
>> ...
> Agreed that the analysis isn't where I'd like it to be yet. There are two major reasons for this. One, this draft is focused on in-band abuse of TCP and IP features (which seemed a good place to start) 

I don't think it is.

A user who doesn't want this sort of vulnerability inside the messages
they send needs to use integrity protection at least (perhaps also
encryption).

A user cannot prevent vulnerabilities in layers they can't control
(e.g., along a tunnel used along a subset of the path).

It's not productive to try to analyze the weaknesses of protocols that
are not designed to be strong. They're weak. Move on, IMO.

The alternative is "hey, it's weak - we should make it strong". Doing
that ends up violating the Postel Principle. I.e., behaviors that are
otherwise legitimate are suddenly interpreted as deliberate and
malicious attacks when they were never specified as such.

That's not helpful, IMO.

Joe

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 29 Jul 2016 23:39:54 +0200

Hi Stephen,

while I personally think that a good protocol design should be extensible because that’s the lesson we learnt over many years now (see draft-iab-protocol-transitions-02), I guess we simply have different opinions here and should leave it stand like this.

> there is wrong, I'd appreciate being corrected.

There are two aspects here:

1) PLUS requires the encryption context from the transport protocol. As PLUS is not a transport protocol in itself, it e.g. cannot provide reliable transmission, which also means it cannot negotiate any encryption context in its own. That means it must use information given from the transport protocol above. If the transport used does not have any of these feature, we have to have another layer in between, namely DTLS.

2) PLUS is a proposal to enable encryption of transport headers because it is just not possible today to encrypt your transport header as it is. Encryption of the TCP header was discussed in tcpinc and decided to not do it because it would cause deployment problem. The minimum you have to do to encrypt your transport header is encapsulation in UDP. However, especially on port 80 this still can lead to blocking. Future providing some information that helps firewalls to make decisions about which traffic is legitimate vs. attack traffic, is necessary to at least maintain the level of security that we have today.

As you said in your mail to Ted, it is hard to decide now what the right set of information is, and my personal opinion is that if we make a decision now and provide no way to change anything later, we can just be wrong.

However, which information should be exposed (when, how and how often) are questions for a wg, as well as any decision on extensibility or not.

Mirja

> Am 29.07.2016 um 21:37 schrieb Stephen Farrell <[email-masked]>:
> 
> 
> Hiya,
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 30 Jul 2016 00:37:33 +0100

Hiya,

On 29/07/16 22:39, Mirja Kühlewind wrote:
> Hi Stephen,
> 
> while I personally think that a good protocol design should be
> extensible because that’s the lesson we learnt over many years now
> (see draft-iab-protocol-transitions-02), I guess we simply have
> different opinions here and should leave it stand like this.

Actually that's an interesting topic. For example the extent to
which TLS ciphersuite's (lack of) structure influenced how we have
now ended up with ~350 entries in that registry; the same actually
goes for TLS extensions which have a truly horrible history (do you
know the one about the extension just to ensure the ClientHello is
not over N and less than M bytes? (Sorry, I forget the values of N
and M, but it's hilarious;-)... and the impact of all that on the
(in)security of the Internet... is something that could be the topic
of an interesting, (if quite astoundingly arcane:-) debate.

I also recall debates about how to usefully allow yet constrain
extensibility in h2.

Both TLS and HTTP are important protocols  and the arguments for
and against extensibility involved are I think quite tricky.

I did btw take a quick flick over the IAB draft you mention above
and I have to say I reckon it needs a lot of work - "Design for
extensibility so that things can be fixed up later" is IMO almost
nonsense, at least as (so baldly) stated.

In this particular case, I think there is a very strong set of
arguments for extremely constrained or no extensibility, perhaps
even to the point of not even starting the work at all.

>> Well, no, PLUS is not a proposal to do that iiuc - PLUS is a
>> proposal to expose some information when such encryption is being
>> done as defined by some other specification which is not PLUS. If
>> my take there is wrong, I'd appreciate being corrected.
> 
> 1) PLUS requires the encryption context from the transport protocol.
> As PLUS is not a transport protocol in itself, it e.g. cannot provide
> reliable transmission, which also means it cannot negotiate any
> encryption context in its own. That means it must use information
> given from the transport protocol above. If the transport used does
> not have any of these feature, we have to have another layer in
> between, namely DTLS.

The phrase "namely DTLS" makes it sound like there is a protocol
proposal somewhere about. Is that the case? I don't think it helps
the argument for PLUS to say "a WG should decide that" myself but
I do understand the tactical logic that might quite reasonably end
up with folks taking that kind of approach. (IOW, I think that the
PLUS BoF would have had a better chance of success had there been
a specific protocol starting point proposed but I understand the
reasons why the proponents might have decided otherwise.)

> 
> 2) PLUS is a proposal to enable encryption of transport headers
> because it is just not possible today to encrypt your transport
> header as it is. 

I think the above sentence isn't helpful. IPsec exists after all.
And while I'm not arguing that IPsec is any part of the answer here
(if there even exists an answer to whatever questions are being
asked), I do think that it's important in this kind of discussion
to be very careful with how we describe things. (Sorry for the
quibble, but the point at issue is whether the PLUS proponents are
or are not correct in concluding that the kind of design for
which you are arguing is or is not necessary.)

> Encryption of the TCP header was discussed in tcpinc
> and decided to not do it because it would cause deployment problem.
> The minimum you have to do to encrypt your transport header is
> encapsulation in UDP. However, especially on port 80 this still can
> lead to blocking. Future providing some information that helps
> firewalls to make decisions about which traffic is legitimate vs.
> attack traffic, is necessary to at least maintain the level of
> security that we have today.

There are far too many statements in the above that claim
certainty in an uncertain world for my tastes.

> 
> As you said in your mail to Ted, it is hard to decide now what the
> right set of information is, and my personal opinion is that if we
> make a decision now and provide no way to change anything later, we
> can just be wrong.

Sure. But we could be wrong to even start that process, if it leads
to the "over 18" problem down the road. I also note that I have yet
to see any of the proponents of PLUS accept that that is a real
problem with any extensible proposal in this space. That lack of
acknowledgement of a real issue seems odd. (Apologies if I missed
such an ack or if it preceded my interest in this topic.)

> 
> However, which information should be exposed (when, how and how
> often) are questions for a wg, as well as any decision on
> extensibility or not.

I don't agree. The charter text that was input to the BoF was very
specific that there would be a registry, and hence extensibility.
I think that is sufficient reason to oppose the creation of a WG
for this topic, for reasons already explained.

Cheers,
S.

>>>>> 2) Further only PLUS provides an additional function that
>>>>> allows to detect any mangling of data/bits that was not
>>>>> intended. This is urgently needed because all the TCP (and
>>>>> higher) layer mangling we see today is the root cause for the
>>>>> problem we have right now.
>>>> 
>>> We explained this in the BoF and I believe I made this point
>>> very clear in my last mail that I replied to Kyle. But let me
>>> state this bit again, because it’s important.
>>> 
>>> Today, there are a large amount of bits a middlebox can mangle
>>> with (as described in draft-trammell-privsec-defeating-tcpip-meta
>>> which is not even exhaustive). Most of the described ways to
>>> insert information into a packet are not detectable, at least
>>> most of the ways described for TCP because all information is in
>>> cleartext and the receiver does not know what the sender has
>>> originally sent while the mangled information still allows proper
>>> operation.
>> 
>> Well, no, PLUS is not a proposal to do that iiuc - PLUS is a
>> proposal to expose some information when such encryption is being
>> done as defined by some other specification which is not PLUS. If
>> my take there is wrong, I'd appreciate being corrected.
>> 
>> few bits of information that might be desirable for the path can
>> be outside the confidentiality envelope.
>> 
>> the sometimes-subtle threats caused by exposing information were
>> to be developed. PLUS however seems to be proposing to go beyond
>> that and to define PDUs, which I think I'm nearly convinced is a
>> bad plan and a path down which it may be better to not start.
>> 
>>> b) provide less bits in a PLUS header, that have been carefully
>>> evaluated towards risks that we know today (but didn’t know when
>>> we designed TCP), and c) a MAC that hashes all information 
>>> channel). This also means that the endpoint has the choice to not
>>> use PLUS (or any PLUS information fields) if mangling is
>>> detected.
>>> 
>>> All these points together, especially point c, makes the
>>> situation compared to what we have today better and not worse!
>> 
>>>> I'm pretty sure that's true - and is part of what puzzles me as
>>>> I said before.
>>>> 
>>>>> Maybe we did not make a great job so far to define PLUS
>>>>> narrowly enough but we believe the actual protocol
>>>>> specification work should be done in a wg to ensure that a
>>>>> broad community can participate, and all concern, including
>>>>> privacy concerns, can be addressed.
>>>> 
>>>> myself amongst them yet or not) fear that any such WG has to
>>>> end up as very privacy unfriendly if it remains transport
>>>> agnostic. From that perspective, starting a WG would not make
>>>> sense.
>>>> 
>>>>> 
>>>>> The point of draft-trammell-privsec-defeating-tcpip-meta is
>>>>> to further explain that the things you describe as risks are 
>>>>> nothing new. And by new, we mean they are even
>>>>> standard-conform; because this is the main point of your
>>>>> concern if I understand you correctly, right?
>>>> 
>>>> all as I read it, so I don't accept the idea that the
>>>> hypercookie is the right place from which to start to analyse
>>>> the set of threats in this space.
>>>> 
>>>> protocol to explicitly enable those same bad behaviours. (It
>>>> could be that not all of us agree that that is a real
>>>> difference.)
>>>> 
>>>>> 
>>>>> intended to signal information from middleboxes to the
>>>>> endpoint (amongst other features). I assume this based on the
>>>>> following statement you made:
>>>>> 
>>>>>> Should we standardise a method for such abuse, then I
>>>>>> think it's quite possible the attacker may argue that their
>>>>>> behaviour is not an attack as it's just a part of "the
>>>>>> standard.“
>>>>> 
>>>>> and
>>>>> 
>>>>>> And to the extent that PLUS could enable and standardise
>>>>>> such things, that is, for me, a major reason to oppose
>>>>>> PLUS.
>>>>> 
>>>>> If the thing you are concerned about in PLUS is, that we
>>>>> propose to standardize ‚option‘ space that explicitly allows
>>>>> middleboxes to add information to a packet, I guess you know
>>>>> that it is possible to define an experimental TCP option (in
>>>>> the ISE stream) without IESG approval that allows the
>>>>> insertion of private information by middleboxes. Even thought
>>>>> TCP options are not intended to be altered by network nodes,
>>>>> there is also no standard that forbids this.
>>>> 
>>>>> Let me say two things about what we ACTUALLY propose with
>>>>> PLUS: 1) We do NOT propose to add space to add arbitrary
>>>>> information. The semantic of the field must be well-defined
>>>>> in an IESG approved RFC and registered respectively.
>>>> 
>>>> IMO that is not sufficient to allay my concern about "over 18"
>>>> and the like. If we build it (the registry) then they will come
>>>> (and ask for or squat on code points with horrible semantics).
>>>> I can't see any way to avoid that other than never creating
>>>> such a registry.
>>>> 
>>>>> This will not only make it not-standard conform to use such
>>>>> a field for something different, it also restrict the set of
>>>>> valid values which then could even be checked by later
>>>>> 2) Further only PLUS provides an additional function that
>>>>> allows to detect any mangling of data/bits that was not
>>>>> intended. This is urgently needed because all the TCP (and
>>>>> higher) layer mangling we see today is the root cause for the
>>>>> problem we have right now.
>>>> 
>>>>> Further, I would like to say that not all middlebox mangling
>>>>> is automatically bad or an attack.
>>>> 
>>>> bad behaviours in this space and we need to worry about us
>>>> maybe legitimising those.
>>>> 
>>>>> middleboxes, it will be even harder to distinguish an attack
>>>>> from something that actually supports the network service
>>>>> provided or even makes the services possible at all. Without
>>>>> standardization there is no control at all. I don’t think we
>>>>> can ignore what’s already happening the Internet any further
>>>>> and providing standardized mechanisms to support the good
>>>>> in-network functions is the only way to improve security for
>>>>> these functions.
>>>> 
>>>> The above text seems indicative of understandable exasperation
>>>> but I don't see how it's very useful for the discussion.
>>>> 
>>>>> 
>>>>>> the argument seems to ignore the downsides of
>>>>>> standardising and thus legitimising "bad" behaviour
>>>>>> including behaviours that your draft properly calls an
>>>>>> attack.
>>>>> 
>>>>  mistake) so I wasn't at all discussing what you or anyone
>>>> wants or doesn't want. It is entirely possible to have good
>>>> motivation for something that may have quite bad side-effects.
>>>> 
>>>>> We propose to standardize a protocol that allows middleboxes
>>>>> to provide information they have been requested for (by the 
>>>>> standard-conform and as bad as the misuse we can see today
>>>>> with existing protocols.
>>>> 
>>>>>>> During the PLUS BoF last week, concern was expressed that
>>>>>>> a generic signaling mechanism such as proposed opened two
>>>>>>> new attack surfaces:
>>>>>> 
>>>>>> No necessarily "opened...new" perhaps more "risked making
>>>>>> much more ubiquitous." At the meeting I didn't hear anyone
>>>>>> claim these were new attacks. (I did hear you say they were
>>>>>> not new.)
>>>>>> 
>>>>>>> 
>>>>>>> metadata injection attacks, where an entity who can
>>>>>>> place devices on a user's access network and has
>>>>>>> information about the user's identity could exfiltrate
>>>>>>> that information to third parties. For purposes of giving
>>>>>>> it a name, let's call this a hypercookie injection attack
>>>>>>> ("hyper" since it exists in a space completely
>>>>>>> (2) Even if path elements are not allowed to say
>>>>>>> anything, a mechanism to allow endpoints to add
>>>>>>> integrity-protected signals to their traffic presents a
>>>>>>> surface for coercion attacks. An access provider can
>>>>>>> force a user to tag traffic with their user ID or some
>>>>>>> other token (a signed assertion that an advertisement has
>>>>>>> been viewed to the end, or maybe even just straight-up
>>>>>>> bitcoins) in order to get "better" connectivity, or even
>>>>>>> any connectivity at all. A more classically Orwellian
>>>>>>> dystopian variant of this attack has a government
>>>>>>> requiring citizens to tag all their outgoing traffic with
>>>>>>> some government-issued identifier. Let's call this a
>>>>>>> hypercookie coercion attack.
>>>>>>> 
>>>>>>> I am less concerned about the surface PLUS presents to
>>>>>>> these attacks than those who have raised the concerns in
>>>>>>> the BoF and on the mailing list, because the current
>>>>>>> Internet architecture is already quite vulnerable to
>>>>>>> them. As I said during my presentation last Thursday, Ted
>>>>>>> Hardie and I sat down to think about this at lunch a
>>>>>>> couple of months ago, and found six ways one could
>>>>>>> execute hypercookie injection or coercion today before
>>>>>>> our pizza showed up.
>>>>>> 
>>>>>> Wrt injection I can buy that totally. Having read your
>>>>>> draft I don't find enough there to accept your assertion
>>>>>> wrt coercion - ISTM that coercion attacks have not been
>>>>>> analysed yet in your draft.
>>>>>> 
>>>>>> As a side-note, meta-data doesn't have to be
>>>>>> person-specific to be controversial - "over 18" and
>>>>>> anything with similar semantics, e.g. "member of <this>
>>>>>> minority" can very clearly be equally or more damaging, yet
>>>>>> totally non-identifying if the relevant set of folks is
>>>>>> large enough. So I wonder if the "hypercookie" concept is
>>>>>> even the right starting point here. And to the extent that
>>>>>> PLUS could enable and standardise such things, that is, for
>>>>>> me, a major reason to oppose PLUS. (That's a side-note for
>>>>>> this email, but perhaps a quite fundamental thing to
>>>>>> consider in the overall discussion.)
>>>>>> 
>>>>>>> 
>>>>>>> I sat down a little longer to write these up. I found
>>>>>>> five more, without even considering trivial out-of-band
>>>>>>> metadata leaks or steganographic side channels. 
>>>>>>> traffic and what will be ignored by TCP-indifferent
>>>>>>> devices and endpoints, as well as all those juicy bits
>>>>>>> IPv6 gives you. Unless we're willing to rely on the
>>>>>>> widespread, altruistic deployment of stateful TCP
>>>>>>> firewalls to reject traffic (I think we can use our
>>>>>>> experience with BCP38 as guidance as to how well *that*
>>>>>>> will work, and in any case I think it would be kind of
>>>>>>> rich for me of all people to recommend throwing more
>>>>>>> TCP-meddling middleboxes into the mix) the only way I can
>>>>>>> see out is to add integrity protection to all transport
>>>>>>> and network-layer headers, as well as confidentiality
>>>>>>> protection to those headers the path does not need to
>>>>>>> see.
>>>>>> 
>>>>>> I don't agree. Observatories seem to me like a mitigation
>>>>>> that your draft does not consider. If the attacker here
>>>>>> does not want to be seen to be attacking, then those can be
>>>>>> effective. Should we standardise a method for such abuse,
>>>>>> then I think it's quite possible the attacker may argue
>>>>>> that their behaviour is not an attack as it's just a part
>>>>>> of "the standard."
>>>>>> 
>>>>>> 4.1.3 of your draft for example so I disagree with the
>>>>>> draft's assertion that "no user-initiated mitigation is
>>>>>> possible" in that case at least and maybe others.
>>>>>> 
>>>>>>> should have a discussion of what the endpoints should be
>>>>>>> able to say, and what the endpoints should be able to let
>>>>>>> the path say. But if we're concerned about this attack,
>>>>>>> the general approach is AFAICT the only way out.
>>>>>> 
>>>>>> standardising and thus legitimising "bad" behaviour
>>>>>> including behaviours that your draft properly calls an
>>>>>> attack.
>>>>>> 
>>>>>> Frankly, I was and remain puzzled by SPUD/PLUS. ISTM that
>>>>>> we have different sets of sensible folks reaching
>>>>>> diametrically opposed conclusions based on the same facts
>>>>>> and arguments. Perhaps the tl;dr in your abstract may be a
>>>>>> hint there - I do not think everything is ruined myself, so
>>>>>> maybe one's level of opt/pess-imism affects one's view of
>>>>>> the valid conclusions to reach in this space.
>>>>>> 
>>>>>> Cheers, S.
>>>>>> 
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> 
>>>>>>> Brian
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> _______________________________________________ Spud
>>>>>> mailing list [email-masked]

---

From: Mirja Kühlewind <[email-masked]>
Date: Sat, 30 Jul 2016 13:07:13 +0200

Hi again,

see below.

> Am 30.07.2016 um 01:37 schrieb Stephen Farrell <[email-masked]>:
> 
> 
> Hiya,
> 

I do see the problems that we have with extensibility and I agree that any new protocol we design needs to consider the mechanism it uses for extensibility carefully. However, I really don’t think that no extensibility is the solution. I don’t think that security would have been better, if TLS has decided for one ciphersuite at the beginning without any option to ever change it… 

Further, the examples you talk about here actually have a very direct impact on security and therefore privacy. If I think about TCP as another example, we do have problem, e.g. option squatting, but the extensibility we have is also key for the success of TCP. TCP would already be dead if we would not have the window scaling option or SACK. 

> nonsense, at least as (so baldly) stated.

Yes, I agree that we probably need further discussion here and that there are different ways to provide extensibility which probably would be good to document. However, there might also not be the one and best solution for all protocols on all layers. I guess we have to make decisions on a case by case basis.

In addition, I would like to mention that there is always a strong desire in transport to miniziae the number of bits to use (as the overhead multiples as the header will be in every packet). For me that’s another reason to support extensibility to make sure that really only those information you need right now show up in the header.

> even to the point of not even starting the work at all.

I disagree. Enabling large scale encryption that is deployable is the goal of PLUS. And this enables two things: increased security and privacy, as well as transport evolution. For the first goal we need encryption and maintain the status quo (regarding network manageability), while for the second part, we envision the development and use of new transports that enable new services. Not having a tool to also enable some innovation in the network to support these services, archives the goal only half way.

> reasons why the proponents might have decided otherwise.)

Yes, we decided to not propose a protocol before the BoF because we wanted to include the community in the design of such a probably important change. We understood from all comments in the BoF that it would be easier for the community to make a decision about the scope of this work if there would be a concrete proposal, and we are working on this.

However, we’ve been talking about the use of DTLS above PLUS since the beginning in the spud BoF in Dallas. We even talked about using extensibility in DTLS to realize PLUS instead of designing an own protocol. However, that has limitations. But it is clear that we need to define PLUS with a tight relation to DTLS, while work on DTLS itself should not be done in a new transport wg. That’s why the charter says: "It will aim to work with working groups defining encryption protocols (e.g. DTLS) which could be used for encryption of transport protocols running over PLUS"

> which you are arguing is or is not necessary.)

Yes, form the technical point of view you have IPSec and yes, from a technical point of view you can basically encrypt everything. However, this sentence was made to talk about the more practical aspects of deployability as it was further stated in the following sentences. 

Please note that these practical deployment consideration also need to consider that even a small amount of blocking might impact the revenue of a service provider. Usually service providers cannot risk that some of their costumer can no be served anymore at all or receive a worse service than currently provided over TCP when deploying a new protocol. That’s why e.g. QUIC implements a fallback to TCP. Given these fallbacks to TCP need to exist, there is actually an incentive to simply block (encrypted) traffic that a network provider does not want to support. Therefore I think it’s extremely important to also provide incentives to network operators to support new protocols.

> certainty in an uncertain world for my tastes.

Yes, this is rather vague but that this is the main problem we have in transport. A large point of your time in all transport wgs is discussing about what is deployable and what not given the ossification we see today. Unfortunately there is no complete view of what happen in the Internet today. We have measurement data that address different angles of the problem but naturally these data is all biased one or the other way. This problem is why we have maprg and why we proposed PLUS as a way forward to address ossification in the transport layer (probably by replacing it with ossification in PLUS, which we call path layer).

> such an ack or if it preceded my interest in this topic.)

We do accept the problem and nearly all the work we did since the spud BoF was addressing this problem. I don’t know why you think that we would not (even) acknowledge the problem. I personally don’t think there is a solution to fully solve the problem though and doing nothing is also not an option because the situation is already bad. However, I personally don’t think that extensibility in it self is the problem. The problem is misuse of new and existing protocols (that leads to (accidental or intentional) leakage of privacy-sensitve information). I'm not sure if there is any solution to completely avoid this misuse (it’s a cat-and-mouse game as the general attacker vs. security problem), based on the Internet that we have today (there might be clean slate solutions…). But what we can do is to make it harder and detectable. That’s the improvement we proposed with PLUS compared to the status quo (which is basically TCP headers in plain).

Again, based on the current deployment it is easy to block new protocols as we basically always can and need to fall back to TCP, and therefore we need to provide network deployment incentives.

> for this topic, for reasons already explained.

Yes the charter say:
"The working group's main output will be an experimental protocol specification, together with an initial registry of types of information that can be exposed using PLUS, clearly aligned to use cases determined by the working group.“

But it also says: 
"The working group will close if it is not able to come to consensus on a protocol design to meet its goals.“

In any case, it’s the wgs decision what to do.

I think this work is needed to address the ossification that we see today by enabling large-scale encryption incl. the transport headers. I think a new protocol is the most promising path to achieve large-scale deployment. All details, including what will be exposed and what goes in a registry or what not or nothing at all, should be discussed in a wg.

I accept you opinion. And I guess we stated our view points clearly and have to let it stand as it is now. However, without being disrespectful but sharing your concerns about privacy (and protocol misuse), I personally don’t think your arguments justify a request for non-extensibility (even tough I would fully expect if a wg would decide to go for an non-extensible approach), and taking this as an argument for "not even starting the work at all“ (see above) does not really makes sense for me. Sorry.

Mirja

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 30 Jul 2016 13:14:14 +0100

Hiya,

I agree with your conclusion that we seem to have clearly set out
where we disagree without so far changing one another's conclusions.
So I only have one more thing to add for now, which is about the
form of, and not the content of, the discussion. You said:

On 30/07/16 12:07, Mirja Kühlewind wrote:
> Enabling large scale encryption that is deployable is the goal of
> PLUS. And this enables two things: increased security and privacy, as
> well as transport evolution. For the first goal we need encryption
> and maintain the status quo (regarding network manageability), while
> for the second part, we envision the development and use of new
> transports that enable new services. Not having a tool to also enable
> some innovation in the network to support these services, archives
> the goal only half way.

I'm fine with and fully accept the first sentence.

The rest of that paragraph however seems to me to beg the question,
that is, it assumes that a deployed PLUS-solution will be an overall
good, when it is exactly that that I and others wish to question. I
do think this is an issue in this discussion and was in the BoF - the
proponents, being convinced that the solution is needed, assume that
the solution is needed when answering those who are questioning
whether we'd be better or worse off should PLUS be developed further.

That's probably natural given folks have been working on SPUD/PLUS
for some time, but it seems to me to hinder discussion with folks like
me who are far from convinced that the envisaged solution is at all
desirable. So my apologies for trying to drag you back to what you
likely consider first principles you probably figured were done with
a couple of years ago, but I think that's actually fair and to be
expected when one has a BoF of this kind.

Cheers,
S.

---

From: Tom Herbert <[email-masked]>
Date: Sat, 30 Jul 2016 10:21:28 -0700

> I disagree. Enabling large scale encryption that is deployable is the goal of PLUS. And this enables two things: increased security and privacy, as well as transport evolution. For the first goal w…
I this is very debatable. The reason we want to encrypt the transport
layer in the first place seems to get easily lost in these
discussions; it is to hide transport layer information *from* the
network. This prevents intrusiveness of the network in transport
layers, stops middleboxes from trying to actively participate in
transport layer protocols, and thus resolves one major source of
protocol ossification and gets us back to the E2E model. The goal of
encryption here is to change the status quo not maintain it!

Tom

---

From: Stephan Neuhaus <[email-masked]>
Date: Sat, 30 Jul 2016 20:24:11 +0200

On 2016-07-30 19:21, Tom Herbert wrote:
> protocol ossification and gets us back to the E2E model.

PLUS offers mostly fields that are set by the endpoints and that are
protected by MACs, so the can't be changed by middleboxes, at least not
without the endpoint finding out. (There are a few fields that are
supposed to enable signaling from the path to the endpoint(s) and these
obviously need to be changeable by the middleboxes. These will be things
such as "tell me the path MTU".)

The PLUS fields will be stuff like "this packet starts a new flow", or
"this packet ends a flow", and the read-only nature of these fields
(unlike what we have now) means that middleboxes can not intrude, and
they can't actively participate. This is exactly what you want, isn't it?

Fun,

Stephan

Full disclosure: I'm working with Brian and Mirja on the MAMI project.

---

From: Stephan Neuhaus <[email-masked]>
Date: Sat, 30 Jul 2016 20:26:21 +0200

On 2016-07-30 19:21, Tom Herbert wrote:
> [...]

I should clarify: when I write "PLUS does this or that", what I mean is
"it is my understanding from the discussions in which I have
participated that PLUS will eventually enable doing this or that". I
have no crystal ball, unfortunately.

Fun,

Stephan
-- 
GPG key ID 4BDA81D3
    fingerprint 5F88 399F 8811 72BE B36A  FC93 4D13 FCB2 4BDA 81D3

---

From: Tom Herbert <[email-masked]>
Date: Sat, 30 Jul 2016 12:59:54 -0700

> they can't actively participate. This is exactly what you want, isn't it?
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). It is therefore incorrect for a
middlebox to assume that it can maintain correct connection state for
any connections. This becomes intrusive when the middlebox makes
decisions based on imperfect state that affects the connection, for
instance when a firewall drops packets for a legitimate established
connection but doesn't have state since it was not in the path of the
SYN.

Thanks,
Tom

---

From: Mirja Kühlewind <[email-masked]>
Date: Sun, 31 Jul 2016 14:57:08 +0200

Hi Stephen,

yes, I believe that the proposed mechanisms are needed (in the first place to address the ossification problem we see in transport - to phrase it at a light level) and yes, I believe that the proposed approaches have the potential to improve but at least doesn’t degrade the situation in general but also the privacy situation that we have today in the Internet. If I wouldn’t believe that, I wouldn’t propose it.

The technical basis for this believe (regarding privacy) is that we propose a mechanism for integrity checking that is stronger than what we have today in transport and therefore makes mangling as least detectable. Further, I believe that only a cooperative approach will enable large-scale encrypting (that includes transport headers) because otherwise operators may be incentivized to block traffic, and in this sense standardization of a mechanism for middlebox communication would draw a much clearer line about what we as a community deem acceptable and what not, instead of declaring all in-network functions other than routing as evil.

I intentionally used the word ‚believe‘ here several times because as stated in my previous mail we just have probably very different starting points. I do think some parts of our discussion involved technical questions, and I hope I could clarify some points. However, other parts of the discussion are naturally more vague because we both don’t know the future. However, in this sense these ‚first principles‘, as I believe you called them below, are purely what people believe. But, please note that one of these ‚first principles‘ is that we in transport see a problem with the ossification today, and PLUS is foremost a proposal to address this problem (by enabling encryption). Given this, I don’t really understand what your comment about the form of the discussion is below. 

However as you mentioned the BoF belong, I actually also have a comment on the form of discussion: this activity is on-going for more than one year. We mainly worked during this time on addressing security questions that were raised at the spud BoF. Based on one request on the mailing before the PLUS BoF we explained how we address privacy concerns and how we think this makes the current situation at least not worse and probably better. We did not get only further feedback on mailing list assuming that our proposal is acceptable. And there was no future discussion about any privacy and security aspects on the list before the BoF. I would really appreciate if people could constructively help us to find a solution to address the ossification problem in transport while maintain or improving the privacy situation we have today, instead of just blocking new work.

Mirja

> Am 30.07.2016 um 14:14 schrieb Stephen Farrell <[email-masked]>:
> 
> 
> Hiya,
>

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 31 Jul 2016 15:05:03 +0100

Hiya,

On 31/07/16 13:57, Mirja Kühlewind wrote:
> Hi Stephen,
> 
> yes, I believe that the proposed mechanisms are needed (in the first
> place to address the ossification problem we see in transport - to
> phrase it at a light level) and yes, I believe that the proposed
> approaches have the potential to improve but at least doesn’t degrade
> the situation in general but also the privacy situation that we have
> today in the Internet. If I wouldn’t believe that, I wouldn’t propose
> it.
> 
> The technical basis for this believe (regarding privacy) is that we
> propose a mechanism for integrity checking that is stronger than what
> we have today in transport and therefore makes mangling as least
> detectable. Further, I believe that only a cooperative approach will
> enable large-scale encrypting (that includes transport headers)
> because otherwise operators may be incentivized to block traffic, and
> in this sense standardization of a mechanism for middlebox
> communication would draw a much clearer line about what we as a
> community deem acceptable and what not, instead of declaring all
> in-network functions other than routing as evil.
> 
> I intentionally used the word ‚believe‘ here several times because as
> stated in my previous mail we just have probably very different
> starting points. I do think some parts of our discussion involved
> technical questions, and I hope I could clarify some points. However,
> other parts of the discussion are naturally more vague because we
> both don’t know the future. However, in this sense these ‚first
> principles‘, as I believe you called them below, are purely what
> people believe. But, please note that one of these ‚first principles‘
> is that we in transport see a problem with the ossification today,
> and PLUS is foremost a proposal to address this problem (by enabling
> encryption). Given this, I don’t really understand what your comment
> about the form of the discussion is below.

Let me try to clarify a couple of important places where my beliefs
and yours don't seem to co-incide:

- I'm not sure the ossification issue is as-it-was 3 years ago,
  given QUIC, and to some extent h2 and TLS1.3, but also due to
  the much increased deployment of TLS. Given such changes, it
  is not at all clear to me that a generic approach (like PLUS
  attempts) is best.
- I am unconvinced that "giving up" some privacy in the manner
  envisaged will lead to an overall privacy benefit. I very much
  fear that opposite - that any extensible mechanism will give up
  so much privacy so as to render much higher layer confidentiality
  moot.

What I meant when referring to first principles was being explicit
in how we're arguing based our these starting points (or beliefs).

My perception of the argument (in this thread and the BoF) is that
it is harder because the proponents of PLUS were assuming sharted
beliefs/starting points when responding to folks who have very
different starting assumptions.

So for example, I don't think I've seen any of the PLUS proponents
directly provide arguments as to why my concerns/beliefs above
are unfounded. (I have seen assertions that they are unfounded but
not arguments starting from assumptions with which I'd agree.) And
my guess is that the proponents are not doing that because they
think it was already done. (If a pointer to the SPUD archive is
usable to answer this point, that's entirely fine.)

> 
> However as you mentioned the BoF belong, I actually also have a
> comment on the form of discussion: this activity is on-going for more
> than one year. We mainly worked during this time on addressing
> security questions that were raised at the spud BoF. Based on one
> request on the mailing before the PLUS BoF we explained how we
> address privacy concerns and how we think this makes the current
> situation at least not worse and probably better. We did not get only
> further feedback on mailing list assuming that our proposal is
> acceptable. And there was no future discussion about any privacy and
> security aspects on the list before the BoF. I would really
> appreciate if people could constructively help us to find a solution
> to address the ossification problem in transport while maintain or
> improving the privacy situation we have today, instead of just
> blocking new work.

Yeah, that's fair. It is of course hard to get input from folks
who are worried that the work as envisaged inevitably leads to a
bad outcome. (So e.g. I'm not subscribed to the SPUD list and am
not sure I'd have time and the energy to be on there constantly
trying to drag you back to 1st principles;-)

Cheers,
S.

>> where we disagree without so far changing one another's
>> conclusions. So I only have one more thing to add for now, which is
>> about the form of, and not the content of, the discussion. You
>> said:
>> 
>>> Enabling large scale encryption that is deployable is the goal
>>> of PLUS. And this enables two things: increased security and
>>> privacy, as well as transport evolution. For the first goal we
>>> need encryption and maintain the status quo (regarding network
>>> manageability), while for the second part, we envision the
>>> development and use of new transports that enable new services.
>>> Not having a tool to also enable some innovation in the network
>>> to support these services, archives the goal only half way.
>> 
>> The rest of that paragraph however seems to me to beg the
>> question, that is, it assumes that a deployed PLUS-solution will be
>> an overall good, when it is exactly that that I and others wish to
>> question. I do think this is an issue in this discussion and was in
>> the BoF - the proponents, being convinced that the solution is
>> needed, assume that the solution is needed when answering those who
>> are questioning whether we'd be better or worse off should PLUS be
>> developed further.
>> 
>> for some time, but it seems to me to hinder discussion with folks
>> like me who are far from convinced that the envisaged solution is
>> at all desirable. So my apologies for trying to drag you back to
>> what you likely consider first principles you probably figured were
>> done with a couple of years ago, but I think that's actually fair
>> and to be expected when one has a BoF of this kind.
>> 
>> Cheers, S.
>> 
>> 
>>> 
>>>>> 
>> 
>

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 31 Jul 2016 17:45:40 +0200

Hi Stephen,

so do you mean future transport protocols (running over UDP) should
define their own protocol specific way of exposing information,
similar to the way QUIC does it?
That would require constant evolution of middleboxes (NAT, firewalls).

Or are you suggesting that future transport protocols should just
use the framing of QUIC (for the unencrypted part) and reuse
the (hopefully) upcoming QUIC support of middleboxes?

Best regards
Michael

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 31 Jul 2016 17:03:18 +0100

> the (hopefully) upcoming QUIC support of middleboxes?

I didn't mean either.

What I meant was that perhaps the analysis that lead to the
conclusions about ossification of the transport layer needs
to be re-done now, give the increase in use of TLS and given
QIUC is now highly likely to be an IETF WG. (That's a similar
question to asking if PLUS is OBE, which I think I asked of
Brian.)

IIUC the IAB w/s that sorta lead to SPUD then PLUS happened
before QUIC was mooted as work in the IETF and before many
services had switched from port 80 to 443.

S.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 31 Jul 2016 18:04:27 +0200

Hi,

>   so much privacy so as to render much higher layer confidentiality

This is the problem with this discussion.  You fear giving up privacy. 
There is no protocol to assuage your fears.  Mirja has said that they
didn't want to propose a protocol, presumably out of appearing to
present a fait accomplit, and round and round we go.  I propose the
following:

Someone show bits, and then let's see if your concerns are borne out or
assuaged.  This argument is too abstract.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 31 Jul 2016 17:13:05 +0100

Hiya,

> assuaged.  This argument is too abstract.

Well yes and no. Yes, I can't see how to assuage the fears of
those with privacy concerns without at least a straw-man. So
the proponent's choice to not provide even that does make the
discussion more abstract and less likely to conclude.

But no, the proponents of the PLUS BoF suggested a charter
that explicitly stated that the solution needed an IANA registry
for extensibility and even specified an update rule for that
putative registry.

I am wholly convinced such a registry with any set of 5226
rules is an error and bad to very bad for privacy. See all the
times I've said "over 18" and similar. I don't think I need to
know more about the on the wire framing of those codepoints
(official or squatted-upon) to reach my conclusion.

Whether a protocol without any extensibility or with some other
extensibility mechanism would be ok or not is not something
about which I've expressed an opinion so far. (Well, at least
I've tried to be neutral, but I fully admit that sometimes what
I try write as neutral, folks read as opinionated;-)

Cheers,
S.

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 31 Jul 2016 21:06:34 +0200

> On 31 Jul 2016, at 18:03, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 
OK.
> question to asking if PLUS is OBE, which I think I asked of
What has changed? Building and deploying UDP based transport
protocols in combination with crypto has been done earlier.
For example in RTMFP by Adobe:
https://tools.ietf.org/html/rfc7016
https://tools.ietf.org/html/rfc7425
Other companies did develop their own protocols and did not
publish it as an RFC.

In the IETF we developed SCTP over UDP and SCTP over DTLS over UDP:
https://tools.ietf.org/html/rfc6951
https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-09

All of these activities (including QUIC) focuses on the end points
and can/are deployed without specific middlebox support.
> services had switched from port 80 to 443.
The crucial point is what was brought up in the QUIC BOF:

Middlebox vendors (I think it was a Firewall vendor at the
mic) explicitly stated that they want to see the QUIC work
done in the IETF such that they can build support for
QUIC in their products.

As far as I understood their argument, it was about knowing
a bit regarding QUIC flows (when is it opened, when closed)
to deal with them. This might result in QUIC specific
support by middleboxes.

SPUD/PLUS would allow this for future transports, if middlebox
vendors would add support for SPUD/PLUS (which they might
or might not do given that there is currently no protocol
using it). So do you think that there is no need for
middleboxes to support transport protocols? That would be
an important point also when looking into the requirements
of QUIC.

Best regards
Michael

---

From: Christian Huitema <[email-masked]>
Date: Sun, 31 Jul 2016 20:10:14 +0000

On Friday, July 29, 2016 5:34 AM, Brian Trammell wrote:

>...
>... As I said
> during my presentation last Thursday, Ted Hardie and I sat down to think
> about this at lunch a couple of months ago, and found six ways one could
> execute hypercookie injection or coercion today before our pizza showed up.
> 
> I sat down a little longer to write these up. I found five more, without even
> considering trivial out-of-band metadata leaks or steganographic side
> channels. https://tools.ietf.org/html/draft-trammell-privsec-defeating-tcpip-
> meta-00 is the result. The conclusion: these attacks are trivially easy to
> execute today by exploiting the gap between valid TCP traffic and what will be
> ignored by TCP-indifferent devices and endpoints, as well as all those juicy bits
> IPv6 gives you...

The original message generated a long thread of comments, but I would like to look back at Brian's draft. First of all, this is an interesting piece of information, and I would like to thank Brian for writing it down. Whether we believe that additional shim headers are wise or not, we should certainly look at current privacy threats against TCP and IP, and as much as possible deploy mitigations.

Here is a set of detailed comments:

- Section 4.1.2, regarding DHCPv6, ought to quote RFC 7844, Anonymity Profiles for DHCP Clients, which specifies mitigations for that threat.

- Section 4.1.3, Identification using IPv6 network address translation, probably needs a bit more context. The NAT can only identify the user context if it links that context to a User-ID, which is somewhat hard for shared connections. But we should take this seriously and develop mitigations, e.g. end-to-end encrypted options that report the address seen by the peer. It would not prevent translation, but it would expose the practice.

- Section 4.2.1.  Fragment Identification Rewriting. Maybe it is time to specify in IP that if the "don't fragment" bit is set, the fragment identifier MUST be set to all zeroes, and SHOULD be reset to zero on reception. If enough end systems and intermediaries do that, this side channel becomes unreliable.

- Section 4.3.  Abusing Transmission Control Protocol Features. All that is true, but it is also part of the rationales for deploying encrypted transports like QUIC. As far as I can tell, none of these attacks apply to QUIC. Which is indeed the point made in section 5.

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. And we could also have recommendations for API designs that expose the received values, so cooperating endpoints could detect alterations.

I think the draft should be extended to also cover UDP, and in particular the side channel created by the potential gap between IP packet length and UDP packet length. My personal preference would be to instruct middleboxes and end-systems to simply drop packets in which UDP length and IP length do not match.

-- Christian Huitema

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 31 Jul 2016 21:13:43 +0100

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

Hence my wondering about PLUS being OBE, despite SCTP etc
substantially pre-dating QUIC. I do think significant port 443
and QUIC deployment may change the landscape in ways that the
definition and implementation of SCTP did not.

> That would be

As I've said a number of times, I think the extensibility
as proposed at the PLUS BoF is the major privacy problem.
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).

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.

And that's before we consider the coercion attack raised
at the BoF and (so far) briefly mentioned in Brian's draft.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 31 Jul 2016 21:14:46 +0100

On 31/07/16 21:10, Christian Huitema wrote:
> First of all, this is an interesting piece of information, and I
> would like to thank Brian for writing it down. Whether we believe
> that additional shim headers are wise or not, we should certainly
> look at current privacy threats against TCP and IP, and as much as
> possible deploy mitigations.

In case my verbosity in this thread has obscured it... I do agree
with the above.

S.

---

From: Brian Trammell <[email-masked]>
Date: Sun, 31 Jul 2016 23:12:48 +0200

hi Eliot, all,

(dropping privsec-program; we're not talking about hypercookies anymore)

> On 31 Jul 2016, at 18:04, Eliot Lear <[email-masked]> wrote:
> 
> Hi,
> 
> 

We think we have a reasonable solution to the transport-independent state exposure problem that doesn't suffer from the issues identified with simple start/stop signaling. Since this been the core of PLUS since before its predecessor was called SPUD, we wanted to nail this down before showing bits. We expect to do this in the next week or so.

Cheers,

Brian

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 31 Jul 2016 23:22:38 +0200

> On 31 Jul 2016, at 22:13, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 
That might be true and is a new flavour of ossification...
Using PLUS would allow multiple transports to be deployed
with the same level of middlebox support (whatever that would
be). I guess this is the difference.
> definition and implementation of SCTP did not.
Sure. SCTP (with UDP encapsulation) hasn't been considered as
a transport for main stream applications. The point of PLUS
is that someone might come up with another transport protocol
optimised for something QUIC is not optimised for and they
wouldn't have to think about middlebox interaction.
Or they can just use the unencrypted QUIC framing as a non-extensible
way of PLUS and do their own protocol in the encrypted part...
> one exists and is useful, which I also don't claim to know).
I see. This is why you are happy with QUIC, but have concerns about
PLUS.
> of the endpoints that are not otherwise exposed.
Sure.

Best regards
Michael

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 31 Jul 2016 17:13:57 -0500

On one specific point ...

On Jul 31, 2016 09:05, "Stephen Farrell" <[email-masked]> wrote:
>   the much increased deployment of TLS.

It seems to me that understanding the current levels and rate of change on
deployment of these technologies would be extremely helpful, given the
discussions we are having.

Spencer

> Given such changes, it

---

From: Tom Herbert <[email-masked]>
Date: Sun, 31 Jul 2016 15:49:22 -0700

> I think the draft should be extended to also cover UDP, and in particular the side channel created by the potential gap between IP packet length and UDP packet length. My personal preference would…
Such an ad hoc policy implemented in middleboxes effectively precludes
the proposed UDP options (draft-touch-tsvwg-udp-options-03) and
provides yet one more example of how protocol ossification kills
innovation.

Tom

---

From: Brian Trammell <[email-masked]>
Date: Mon, 1 Aug 2016 01:33:43 +0200

hi Stephen,

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

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

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

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

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

> as proposed at the PLUS BoF is the major privacy problem.

Speaking for myself: I've heard you. 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.

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

> of the endpoints that are not otherwise exposed.

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

> 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. I still don't buy the assertion that PLUS expands this surface.

Regards,

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 1 Aug 2016 02:01:23 +0100

Hiya,

On 01/08/16 00:33, Brian Trammell wrote:
>>> So do you think that there is no need for middleboxes to support
>>> transport protocols?
>> 
>> 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.

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

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

---

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

On 7/30/16 9:59 PM, Tom Herbert wrote:
> 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