[Spud] Extensibility considered harmful? was Re: [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks

Brian Trammell <ietf@trammell.ch> Sun, 31 July 2016 21:12 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 188A112B069 for <spud@ietfa.amsl.com>; Sun, 31 Jul 2016 14:12:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.189
X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id yWJPilkwruBk for <spud@ietfa.amsl.com>; Sun, 31 Jul 2016 14:12:50 -0700 (PDT)
Received: from trammell.ch (trammell.ch []) by ietfa.amsl.com (Postfix) with ESMTP id 3C26F12D0D8 for <spud@ietf.org>; Sun, 31 Jul 2016 14:12:50 -0700 (PDT)
Received: from [] (dynamic-94-247-222-033.catv.glattnet.ch []) by trammell.ch (Postfix) with ESMTPSA id CA0041A0128; Sun, 31 Jul 2016 23:12:48 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_4A9223D6-710D-4C07-8EE2-CB87EB42EDA6"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <240cab8d-8e5b-4fa6-c45a-0389a4b499e2@cisco.com>
Date: Sun, 31 Jul 2016 23:12:48 +0200
Message-Id: <0AADE895-353A-4860-AA4F-8D8C3E1F5C2D@trammell.ch>
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> <240cab8d-8e5b-4fa6-c45a-0389a4b499e2@cisco.com>
To: Eliot Lear <lear@cisco.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/aWASYaBY__MRBEu-qI_Ssg-0P5I>
Cc: spud <spud@ietf.org>, =?utf-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: [Spud] Extensibility considered harmful? was Re: [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:12:52 -0000

hi Eliot, all,

(dropping privsec-program; we're not talking about hypercookies anymore)

> On 31 Jul 2016, at 18:04, Eliot Lear <lear@cisco.com> wrote:
> Hi,
> On 7/31/16 4:05 PM, Stephen Farrell wrote:
>> - I am unconvinced that "giving up" some privacy in the manner
>>  envisaged will lead to an overall privacy benefit. I very much
>>  fear that opposite - that any extensible mechanism will give up
>>  so much privacy so as to render much higher layer confidentiality
>>  moot.
> This is the problem with this discussion.  You fear giving up privacy.
> There is no protocol to assuage your fears.  Mirja has said that they
> didn't want to propose a protocol, presumably out of appearing to
> present a fait accomplit, and round and round we go.  I propose the
> following:
> Someone show bits, and then let's see if your concerns are borne out or
> assuaged.  This argument is too abstract.

We think we have a reasonable solution to the transport-independent state exposure problem that doesn't suffer from the issues identified with simple start/stop signaling. Since this been the core of PLUS since before its predecessor was called SPUD, we wanted to nail this down before showing bits. We expect to do this in the next week or so.