[Spud] Detecting and Defeating TCP/IP Hypercookie Attacks

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

Return-Path: <ietf@trammell.ch>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7549612D0F8 for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 05:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.189
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id aSb31_1U5EoN for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 05:33:41 -0700 (PDT)
Received: from trammell.ch (trammell.ch []) by ietfa.amsl.com (Postfix) with ESMTP id 97F7C12B012 for <spud@ietf.org>; Fri, 29 Jul 2016 05:33:41 -0700 (PDT)
Received: from [] (dynamic-94-247-222-033.catv.glattnet.ch []) by trammell.ch (Postfix) with ESMTPSA id A22661A13A3; Fri, 29 Jul 2016 14:33:40 +0200 (CEST)
From: Brian Trammell <ietf@trammell.ch>
X-Pgp-Agent: GPGMail
Content-Type: multipart/signed; boundary="Apple-Mail=_12F76895-1192-4E0D-B5D2-4772C7FA22BB"; protocol="application/pgp-signature"; micalg=pgp-sha512
Date: Fri, 29 Jul 2016 14:33:39 +0200
Message-Id: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch>
To: spud <spud@ietf.org>, privsec-program@iab.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/H6cjJ4R7kLrcQpIwxeSSg2OS3bw>
Subject: [Spud] 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 12:33:43 -0000

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.