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

Tom Herbert <tom@herbertland.com> Fri, 29 July 2016 17:13 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 8E0B312DB6D for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 10:13:08 -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=ham 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 Z3JlNeyPYm3Y for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 10:13:07 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 D53C512DC0C for <spud@ietf.org>; Fri, 29 Jul 2016 10:12:49 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id f6so197900963ith.1 for <spud@ietf.org>; Fri, 29 Jul 2016 10:12:49 -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=SM03YCmB5I4O4s96Bm5o+MoBM0m9MOL1DjY2KjA5yHg=; b=gnWEaHyJLVrYqAyvIvSi3Axm87Z4fxwYs6UZ9r7wVBMT+DTjwf1q0+InqyG+Gu2fjQ IaVz9lRwAA1TvWFLs1VudLJKgQsVHGW60isvsG1a1TlR8KKilgxHhg+qW/9ACSpgVzAz kMtwtqRZYA5UUqC1l4iLKVhb1rE+zjDziHt24fnpM6I0HmTckuXXm84cAkfK3MShYgCr aB/gVSCJh84lt+RgZMoTZ1mv/0a+J2DjbhCoVkym/+/CfoPr1KFlWuwg99sNzr8OzFHb Tm8gj1/bQl/lAB2rJmkOW6R/WIh6Piuq7b0C1Md/1o2LN9GDg1/WbbqOlSqfHfz9h4Hg F+RQ==
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=SM03YCmB5I4O4s96Bm5o+MoBM0m9MOL1DjY2KjA5yHg=; b=dE9h7rnJ1ZxHSx8eJmztUHk0SHTUqNtkX/T2j7sDKmRvvhRXpkgkJvtLoV1TYJ/yCK dtCowOVF5+KlLLZpOks8g/Mpg5EqdJrARPA+gZFh8asowdNRSFmDEAi3xyS/TiiAuhZh jSw//LROFCV6mXoNxSapkV5KAVxAXxEl0EbHQi1SXPRF8KjhLRHf918zXBfE6JdIXIk2 NjheCTuliUuPhnhphkEAUovOBn/OWya4/pD5THBRg6HkgO9g55+qNop07tjQn9Ga5Tce 1bgXkNYYRzMbBCUQ9QH2H293mBwf+3k0hNImLPfsEvMtyRbok2NnHgZMfR/AMPUEzFSd FExg==
X-Gm-Message-State: AEkoouvxhN7mw2OY2DQ0lZSU5McwOmCJnW423Bmx4AHHNS44Ae/0Gfa5C4XwaV3xOsa4VLll3sUVwWzeE6DAeQ==
X-Received: by 10.36.16.197 with SMTP id 188mr46929208ity.88.1469812368644; Fri, 29 Jul 2016 10:12:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.21.130 with HTTP; Fri, 29 Jul 2016 10:12:48 -0700 (PDT)
In-Reply-To: <A29F376F-3775-4E48-97EE-2DD4208ADC0C@trammell.ch>
References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <CALx6S37s-FM13seA28vd_gahYJbqo_sq+RB-S5LEzKRCYKzh0w@mail.gmail.com> <A29F376F-3775-4E48-97EE-2DD4208ADC0C@trammell.ch>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 29 Jul 2016 10:12:48 -0700
Message-ID: <CALx6S35G3UPcAj_Wt+zNDH2vbakiXrXPpRJR0XmW-5Kn4-tVeg@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/WujyyKB3Hbo5Xu1L0UqiJK58Mgo>
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 17:13:08 -0000

On Fri, Jul 29, 2016 at 9:29 AM, Brian Trammell <ietf@trammell.ch>; wrote:
> Hi, Tom,
>
>> On 29 Jul 2016, at 17:49, Tom Herbert <tom@herbertland.com>; wrote:
>>
>> 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.
>
> Nope. I don't need to touch the endpoints at all for an injection attack. I just need one middlebox near the source to rewrite packets, and (possibly) another one downstream to pick up the signals. (Okay, I might need to hack the kernel on my middleboxes. But I get to do that. They're mine. :) )
>
Except that middelboxes presumably do not have access to the encrypted
data so the amount of information they can derive from the packet is
limited. The problem is when the application or user is being coerced
and there is a readily available mechanism that facilitates that. For
example, it seems very possible that a rich signaling mechanism
implemented by the user could be used to enforce a backdoor to
encryption.

Tom