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

Tom Herbert <tom@herbertland.com> Fri, 29 July 2016 15:49 UTC

Return-Path: <tom@herbertland.com>
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 8526C12D669 for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 08:49:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 a8LHxdqOOtB4 for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 08:49:47 -0700 (PDT)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6939112D18F for <spud@ietf.org>; Fri, 29 Jul 2016 08:49:47 -0700 (PDT)
Received: by mail-io0-x231.google.com with SMTP id q83so132796816iod.1 for <spud@ietf.org>; Fri, 29 Jul 2016 08:49:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=cLvx+iGBmTjF68FpIX64QLb0PoZjYRbJbY12MMXlpHg=; b=19CkmSejKhjnjn8/1OZcJauTMuSLkrlgexK5+GCUNQKddKadtad82igPoVDRlcPWy7 VYIobgyVqma1v4+SeL4bSTLpGHXugZdSlIjTUgRCyhROsiGekAi9Ru8AQt4rerV2tRlU gg/RjHnjyoMPgYCxo3kaDZjxAqTS4Tn9qnygzyEDp8gLvvj+1bpgLfG+iGBFhC27oiEp KJRW0ci2cdx/q0g7yUJ5+wl0IvBTi/jbuzrThoJQxuv8ToR6ywTDOxxFm1iQOL20oWsj KrjU3M7rMrvMeZtPkRLalSLrIFq1wnnCq1HHbzG4CFi9Vl6oZrU9wsxaQ5SRoauPNryX 3Jyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=cLvx+iGBmTjF68FpIX64QLb0PoZjYRbJbY12MMXlpHg=; b=SdMcMT/reMIr/dMSlGw4H2SJRpNDmm46Vt6IozlCe1I3sEgpHPI3FjJYAEbSSoXyxS ksE4ruTedLQE3MIZTqL0AfuWgYWv93Rm6O/F3koPKOXzBNXF45H2K/B8+LpQHWyoypPW nIRjkucPPsK0IMgB7FHBM/egUpcdACFfZG49IZwrA5NC8yj8/bwQqvf9dSuGnKV34Gno p2Q7y7YZMTzncnVDnnwTohzpAS8prD84JLHwFp4XQrhyvGwNiVaAWlD53nO89LE58i9U 91qd9EmWM5gs78K57cdsltmiC9hsskoMMHItYfE9hf2LzHyBdGAGyXdaAX0CBnCcNV7z KH4A==
X-Gm-Message-State: AEkoouuI0OESyWNe9yRn955FtulW2yRuvEhRVDQDS1BQnvaom+gk42X4KAmkQs18VNcurO8JDR3JU4j0yQYBcg==
X-Received: by 10.107.11.74 with SMTP id v71mr50792582ioi.107.1469807386683; Fri, 29 Jul 2016 08:49:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.21.130 with HTTP; Fri, 29 Jul 2016 08:49:46 -0700 (PDT)
In-Reply-To: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch>
References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 29 Jul 2016 08:49:46 -0700
Message-ID: <CALx6S37s-FM13seA28vd_gahYJbqo_sq+RB-S5LEzKRCYKzh0w@mail.gmail.com>
To: Brian Trammell <ietf@trammell.ch>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/1Ww2dYaaHg23NkQ3m8hTnhMOFVg>
Cc: privsec-program@iab.org, spud <spud@ietf.org>
Subject: Re: [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 15:49:49 -0000

On Fri, Jul 29, 2016 at 5:33 AM, Brian Trammell <ietf@trammell.ch>; 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:
>
> (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.
>
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