IETF Logo Mail Archive

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

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Sun, 31 July 2016 21:22 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 D059612D0A8 for <spud@ietfa.amsl.com>; Sun, 31 Jul 2016 14:22:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.888
X-Spam-Level:
X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
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 SejHiBQs45A0 for <spud@ietfa.amsl.com>; Sun, 31 Jul 2016 14:22:44 -0700 (PDT)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073AE12D0D8 for <spud@ietf.org>; Sun, 31 Jul 2016 14:22:44 -0700 (PDT)
Received: from [192.168.1.7] (p4FE312A4.dip0.t-ipconnect.de [79.227.18.164]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 4EAC1721E280D; Sun, 31 Jul 2016 23:22:41 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <45d1e4f8-43fd-181f-b902-73f129e8518b@cs.tcd.ie>
Date: Sun, 31 Jul 2016 23:22:38 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <531F6161-E6C6-4D1E-AC3E-DDD4BD72CCAA@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> <45d1e4f8-43fd-181f-b902-73f129e8518b@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/3Nsu4vkNxRrDuMJ_aEbqlswRP5I>
Cc: Brian Trammell <ietf@trammell.ch>, privsec-program@iab.org, Mirja Kühlewind <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 21:22:46 -0000

> On 31 Jul 2016, at 22:13, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> 
> 
> 
> 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
That might be true and is a new flavour of ossification...
Using PLUS would allow multiple transports to be deployed
with the same level of middlebox support (whatever that would
be). I guess this is the difference.
> 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.
Sure. SCTP (with UDP encapsulation) hasn't been considered as
a transport for main stream applications. The point of PLUS
is that someone might come up with another transport protocol
optimised for something QUIC is not optimised for and they
wouldn't have to think about middlebox interaction.
Or they can just use the unencrypted QUIC framing as a non-extensible
way of PLUS and do their own protocol in the encrypted part...
> 
>> 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 see. This is why you are happy with QUIC, but have concerns about
PLUS.
> 
> 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.
Sure.

Best regards
Michael
> 
> And that's before we consider the coercion attack raised
> at the BoF and (so far) briefly mentioned in Brian's draft.
> 
> Cheers,
> S.
> 
>

v2.23.0 | Report a Bug | By Email