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

Tom Herbert <tom@herbertland.com> Sun, 31 July 2016 22: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 70A8112B059 for <spud@ietfa.amsl.com>; Sun, 31 Jul 2016 15:49:26 -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 OVp2vMP1Idci for <spud@ietfa.amsl.com>; Sun, 31 Jul 2016 15:49:24 -0700 (PDT)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 7F3BE12B03D for <spud@ietf.org>; Sun, 31 Jul 2016 15:49:24 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id u186so231490622ita.0 for <spud@ietf.org>; Sun, 31 Jul 2016 15:49:24 -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=piv/IceWdZHY+trR9ccb7H2ZfunqIw1CJdrGKJjgW1A=; b=pFoA8r9qJH8TFv9PoNUaLPgw/u2Z99F0iiGZ/u8OrFDju2F/sNrQXUWAVt3NwOQZy1 y2grOuk+cqOYZt4eExC6Xlal30yUnkourPDKXBaZMcnUrZOW6yV4Nwzc6U5rnDhAQpGb NwGZg3Ta4OcRvP5p+VRteLn7FDhAk2/V7tUwFTJAPWKH3TD62zUeTjkkPhtHk/E+FjRs t3mNvFdBS80ag4WIyeiTiGmP8psOj2Ir70NHF6vb4kUw4BC6t+DCVQJIhkmeyEJmvnM2 5SeFER0Jd6OzJOVJYEW6WsEL2S7CyTbyERgZJzyfSJBDozaDtyYN4h2Sw8NrTTgxdnjJ CE2Q==
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=piv/IceWdZHY+trR9ccb7H2ZfunqIw1CJdrGKJjgW1A=; b=Yy21qD8Y4LuZ9Wb/QZBNjh7fvr48cbJeNEV83zt8heHR1MBktxaXqPc0BammIx49ex Mqq9fi7ePL2XRH85kz6AnH0b+THo4NfLVns61mE13usUzOfWKoCxotKat4vlblIev9jo 7Qtd8s9DlVYfminquDatuivv0xfVlbQbQvOZdOBlNCKPz+brfZBJyWAD9NC9dAoIWckx 9DTNd+MQD+TfNYqqQgJs/7JPUrvL5qT9tCX7oOP9oMRIFUuw6MHjZYjJvyb2ilvdz17G 8p6EVwxUitqn/iwGPqPe23l1CPzCfD2D++3nzKd0D37QyKqLB/z+l0vBIx3lu5q40aOQ 55rg==
X-Gm-Message-State: AEkoouu6cox84KYslwA7q0V50NrhhDW0mJuWR00JwPRf8m3xO3uf8qzAOJqe7AvL0C8bUW70CRjhEUNjhr7jhw==
X-Received: by 10.36.51.206 with SMTP id k197mr33628872itk.37.1470005363602; Sun, 31 Jul 2016 15:49:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.21.130 with HTTP; Sun, 31 Jul 2016 15:49:22 -0700 (PDT)
In-Reply-To: <BN6PR03MB2675EC471209B4105DFFFD37A8030@BN6PR03MB2675.namprd03.prod.outlook.com>
References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <BN6PR03MB2675EC471209B4105DFFFD37A8030@BN6PR03MB2675.namprd03.prod.outlook.com>
From: Tom Herbert <tom@herbertland.com>
Date: Sun, 31 Jul 2016 15:49:22 -0700
Message-ID: <CALx6S37z44mgqqcGTNxr6Sz9s05E9EpQq9KX5M+78uC8eYLFXg@mail.gmail.com>
To: Christian Huitema <huitema@microsoft.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/pZNdBdqmaLzK4oeltbT4rKQL4qY>
Cc: Brian Trammell <ietf@trammell.ch>, 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: Sun, 31 Jul 2016 22:49:27 -0000

On Sun, Jul 31, 2016 at 1:10 PM, Christian Huitema
<huitema@microsoft.com> wrote:
> On Friday, July 29, 2016 5:34 AM, Brian Trammell wrote:
>
>>...
>>... 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...
>
> The original message generated a long thread of comments, but I would like to look back at Brian's draft. First of all, this is an interesting piece of information, and I would like to thank Brian for writing it down. Whether we believe that additional shim headers are wise or not, we should certainly look at current privacy threats against TCP and IP, and as much as possible deploy mitigations.
>
> Here is a set of detailed comments:
>
> - Section 4.1.2, regarding DHCPv6, ought to quote RFC 7844, Anonymity Profiles for DHCP Clients, which specifies mitigations for that threat.
>
> - Section 4.1.3, Identification using IPv6 network address translation, probably needs a bit more context. The NAT can only identify the user context if it links that context to a User-ID, which is somewhat hard for shared connections. But we should take this seriously and develop mitigations, e.g. end-to-end encrypted options that report the address seen by the peer. It would not prevent translation, but it would expose the practice.
>
> - Section 4.2.1.  Fragment Identification Rewriting. Maybe it is time to specify in IP that if the "don't fragment" bit is set, the fragment identifier MUST be set to all zeroes, and SHOULD be reset to zero on reception. If enough end systems and intermediaries do that, this side channel becomes unreliable.
>
> - Section 4.3.  Abusing Transmission Control Protocol Features. All that is true, but it is also part of the rationales for deploying encrypted transports like QUIC. As far as I can tell, none of these attacks apply to QUIC. Which is indeed the point made in section 5.
>
> The draft mentions the IPv6 flow-ID, but creative intermediaries might also manipulate the TOS fields, so maybe there should be a subsection describing that too. And we could also have recommendations for API designs that expose the received values, so cooperating endpoints could detect alterations.
>
> I think the draft should be extended to also cover UDP, and in particular the side channel created by the potential gap between IP packet length and UDP packet length. My personal preference would be to instruct middleboxes and end-systems to simply drop packets in which UDP length and IP length do not match.
>
Such an ad hoc policy implemented in middleboxes effectively precludes
the proposed UDP options (draft-touch-tsvwg-udp-options-03) and
provides yet one more example of how protocol ossification kills
innovation.

Tom