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

[Mirja Kühlewind <[e-mail]>]

Hi again,

see below.

> Am 30.07.2016 um 01:37 schrieb Stephen Farrell <[e-mail]>:
> 
> 
> 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 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. 

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

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.

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

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.

> 
>> 
>> One point I want to clarify (as you asked for it):
>> 
>>> 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.
>> 
>> 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.
> 
> 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.)

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"

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

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.

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

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

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

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.

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

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


> 
> Cheers,
> S.
> 
>> 
>> Mirja
>> 
>> 
>>> Am 29.07.2016 um 21:37 schrieb Stephen Farrell
>>> <[e-mail]>:
>>> 
>>> 
>>> 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.)
>>> 
>>>> 
>>>> 
>>>> To answer your question below:
>>>> 
>>>>>> 
>>>>>> 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?
>>>> 
>>>> 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.
>>> 
>>> 
>>>> 
>>>> Mirja
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> Am 29.07.2016 um 17:17 schrieb Stephen Farrell 
>>>>> <[e-mail]>:
>>>>> 
>>>>> 
>>>>> 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.
>>>>>> 
>>>>>> Otherwise can you please further explain what you mean by
>>>>>> „such abuse“ and „such things“?
>>>>> 
>>>>> 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.
>>>>> 
>>>>>> 
>>>>>> To make this even more clear, you wrote:
>>>>>>> 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.
>>>>> 
>>>>>> 
>>>>>> Mirja
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Am 29.07.2016 um 15:23 schrieb Stephen Farrell 
>>>>>>> <[e-mail]>:
>>>>>>> 
>>>>>>> 
>>>>>>> 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 [e-mail] 
>>>>>>>> https://www.iab.org/mailman/listinfo/privsec-program
>>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________ Spud
>>>>>>> mailing list [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/spud
>>>>>> 
>>>>> 
>>>>> _______________________________________________ Spud mailing
>>>>> list [e-mail] https://www.ietf.org/mailman/listinfo/spud
>>>> 
>>>> _______________________________________________ Privsec-program 
>>>> mailing list [e-mail] 
>>>> https://www.iab.org/mailman/listinfo/privsec-program
>>>> 
>>> 
>> 
>> _______________________________________________ Privsec-program
>> mailing list [e-mail] 
>> https://www.iab.org/mailman/listinfo/privsec-program
>> 
>