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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 31 July 2016 20:13 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 187A212D0A7 for <spud@ietfa.amsl.com>; Sun, 31 Jul 2016 13:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.588
X-Spam-Level:
X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 Hf_i1OO9c7HM for <spud@ietfa.amsl.com>; Sun, 31 Jul 2016 13:13:49 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AC8712B027 for <spud@ietf.org>; Sun, 31 Jul 2016 13:13:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 46064BE75; Sun, 31 Jul 2016 21:13:46 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0Se9rj0OXoh; Sun, 31 Jul 2016 21:13:44 +0100 (IST)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id ECC1CBE73; Sun, 31 Jul 2016 21:13:43 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1469996024; bh=0MagIxt7DmHXmYPOR33TWTMItQkop5B7vbBUzkGgSjg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=LmJgowESTTX+EAk10YlYnOGDhqlCIek7wvp5/TqSLQXZxdTuML3LwMQcGZszzAPjP p+GNqZDwUzxp6QFiqxU36QY7/zCeCFV+XaGlEDzfvW91kiaCGMKrcqQzsA0v3hoNwR 1ujMQLzSFCLXOSewVkHcvBCjcWn3EC1m3cIh/25Q=
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <d27266cf-87f6-17b1-3038-e0f614c6c773@cs.tcd.ie> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <dc29fa73-88fd-3dc4-7497-f1bd2fa60422@cs.tcd.ie> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <D2CEDF13-E508-4732-B8F6-98FBBDDC7EE6@tik.ee.ethz.ch> <f5c06c8a-5bef-86f6-5c62-302e7f6f75bf@cs.tcd.ie> <B58C7986-4B91-41FB-A6B6-F8E7BD25E799@tik.ee.ethz.ch> <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie> <F7541B2E-86C2-49C6-B616-BDCC567CDAFC@lurchi.franken.de> <92b31df8-f557-a935-a3d8-1f7bf7ee8689@cs.tcd.ie> <E9B17055-DB61-41C6-9D9F-7510E9EC1ADE@lurchi.franken.de>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <45d1e4f8-43fd-181f-b902-73f129e8518b@cs.tcd.ie>
Date: Sun, 31 Jul 2016 21:13:43 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <E9B17055-DB61-41C6-9D9F-7510E9EC1ADE@lurchi.franken.de>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090801070609080008090501"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/-gfr5232SIRGS5oJAzYxdnJ2X6A>
Cc: Brian Trammell <ietf@trammell.ch>, privsec-program@iab.org, =?UTF-8?Q?Mirja_K=c3=bchlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, 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: Sun, 31 Jul 2016 20:13:51 -0000


On 31/07/16 20:06, Michael Tuexen wrote:
> So do you think that there is no need for
> middleboxes to support transport protocols? 

I have no strong opinions on that.

I would be surprised if middleboxes wanted to support PLUS
if they think that QUIC is what will be widely deployed. But
then I am often surprised;-)

Hence my wondering about PLUS being OBE, despite SCTP etc
substantially pre-dating QUIC. I do think significant port 443
and QUIC deployment may change the landscape in ways that the
definition and implementation of SCTP did not.

> That would be
> an important point also when looking into the requirements
> of QUIC.

As I've said a number of times, I think the extensibility
as proposed at the PLUS BoF is the major privacy problem.
I've also said that I'm so far neutral on a non-extensible
way of exposing some transport information to the path (if
one exists and is useful, which I also don't claim to know).

I would however be opposed if "transport information" is so
broadly interpreted as to include identifiers or generic attributes
of the endpoints that are not otherwise exposed.

And that's before we consider the coercion attack raised
at the BoF and (so far) briefly mentioned in Brian's draft.

Cheers,
S.