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

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Fri, 29 July 2016 15:54 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E330C12B05C for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 08:54:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Level:
X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZOlfaomR-AZ for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 08:54:54 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F25E12B042 for <spud@ietf.org>; Fri, 29 Jul 2016 08:54:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C77ADD930B; Fri, 29 Jul 2016 17:54:52 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tvKRzQqIrQXd; Fri, 29 Jul 2016 17:54:52 +0200 (MEST)
Received: from [192.168.178.33] (p5DEC2F34.dip0.t-ipconnect.de [93.236.47.52]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 761E2D9307; Fri, 29 Jul 2016 17:54:52 +0200 (MEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: =?utf-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>
In-Reply-To: <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie>
Date: Fri, 29 Jul 2016 17:54:51 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch>
References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <d27266cf-87f6-17b1-3038-e0f614c6c773@cs.tcd.ie> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/sHAcazuArVC3Z_3uA0C9WBwSJX0>
Cc: Brian Trammell <ietf@trammell.ch>, privsec-program@iab.org, spud <spud@ietf.org>
Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2016 15:54:58 -0000

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. 

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.

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 <stephen.farrell@cs.tcd.ie>;:
> 
> 
> 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
>>> <stephen.farrell@cs.tcd.ie>;:
>>> 
>>> 
>>> 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 Privsec-program@iab.org 
>>>> https://www.iab.org/mailman/listinfo/privsec-program
>>>> 
>>> 
>>> _______________________________________________ Spud mailing list 
>>> Spud@ietf.org https://www.ietf.org/mailman/listinfo/spud
>> 
> 
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud