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

Brian Trammell <ietf@trammell.ch> Fri, 29 July 2016 16:23 UTC

Return-Path: <ietf@trammell.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 2307412D7F1 for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 09:23:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.189
X-Spam-Level:
X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 C6LAcRzHsSqB for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 09:22:58 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id F0F3C12D7D9 for <spud@ietf.org>; Fri, 29 Jul 2016 09:22:57 -0700 (PDT)
Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id 5C22C1A0C60; Fri, 29 Jul 2016 18:22:56 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_6E0BF960-CC03-4C87-AB51-E5780A116250"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <d27266cf-87f6-17b1-3038-e0f614c6c773@cs.tcd.ie>
Date: Fri, 29 Jul 2016 18:22:55 +0200
Message-Id: <A0A36FD7-3494-4BC3-9C68-FD58A55DF087@trammell.ch>
References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <d27266cf-87f6-17b1-3038-e0f614c6c773@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/K7ayPdKtnmS-aE64Fk2IAmQ2SIU>
Cc: 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 16:23:00 -0000

hi Stephen,

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

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

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

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.

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

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

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

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

> I think it'd be a fine thing to see further analysis of the attacks
> 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.

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

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.

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

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