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

Brian Trammell <ietf@trammell.ch> Sun, 31 July 2016 23:33 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 EBCA812D0AD for <spud@ietfa.amsl.com>; Sun, 31 Jul 2016 16:33:48 -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 dAm1707l4dKL for <spud@ietfa.amsl.com>; Sun, 31 Jul 2016 16:33:47 -0700 (PDT)
Received: from trammell.ch (trammell.ch []) by ietfa.amsl.com (Postfix) with ESMTP id A161412B01F for <spud@ietf.org>; Sun, 31 Jul 2016 16:33:45 -0700 (PDT)
Received: from [] (dynamic-94-247-222-033.catv.glattnet.ch []) by trammell.ch (Postfix) with ESMTPSA id 3AB801A04CE; Mon, 1 Aug 2016 01:33:44 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_914402AD-4CB3-42C6-A7BB-BB760651854B"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <45d1e4f8-43fd-181f-b902-73f129e8518b@cs.tcd.ie>
Date: Mon, 1 Aug 2016 01:33:43 +0200
Message-Id: <B018BDCD-64EF-4F86-9B0B-FA73EA63A5C9@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> <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/t2sPeDaldrBpfBN0AzguiQOIIiw>
Cc: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>, =?utf-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, spud <spud@ietf.org>
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 23:33:49 -0000

hi Stephen,

A couple of points inline:

> 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
> then I am often surprised;-)

QUIC is a single transport protocol, designed for a fairly specific kind of interaction (H2, and things that look a lot like it; "fully-reliable discrete object transfer" might be a suitable name for this class of application).

Despite the fact that "web" and "internet" (in the lower-case, AP-style-guide sense) are often used interchangeably, other applications exist. Interactive video is one of the biggest of these by volume on the Internet. While it can be and has been wedged into HTTP (largely due to the ossification PLUS is intended to combat), it is a bad fit. Even the design of non-interactive video over HTTP implies a good deal of inefficiency, in part due to that "fully-reliable".

If we would like the benefits of transport header integrity to accrue to these applications as well (and I hope I've made the case that we do), there are a few things we can do:

(1) Design a common wire image for new transports (most of which in the intermediate term will probably have to slot over UDP, as QUIC does). This is the PLUS approach.

(2) Realize we'll probably only get one more chance to deploy a new transport in the next two decades, and make QUIC work well for other points in the application design space. This would come at a cost of complexity in the design and implementation of QUIC.

(3) Don't expand QUIC's design, but wedge these new applications over QUIC even though it's a terrible fit. This at least has the benefit of complying with tradition. :)

(4) Have other new transports' wire images look like a transport that is already widely deployed. If QUIC becomes successful, I would expect to see at least experiments to get other non-QUIC protocols to look like QUIC on the wire, a la TCP Minion.

Note that when discussing QUIC, it is of course important to distinguish the Google QUIC experiment from the protocol that the QUIC WG (which I presume will be formed) will standardize. So (3) and (4) might actually be talking about two subtly different QUICs when considering the transition to the standard. SPDY/H2 has at least shown that we know how to make this transition work relatively quickly (or is that speedily? ;) )

> Hence my wondering about PLUS being OBE, despite SCTP etc
> substantially pre-dating QUIC. I do think significant port 443

Nope: HTTPS over tcp/443 does nothing at all for making it possible to deploy applications that don't wedge nicely atop HTTP, nothing at all for running those over anything but TCP, and nothing for transport header integrity.

> and QUIC deployment may change the landscape in ways that the
> definition and implementation of SCTP did not.

QUIC deployment did indeed change the landscape: it added 2 and 3 to the list above. Both are extremely suboptimal.

>> 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.

Speaking for myself: I've heard you. I continue to disagree (vehemently) that zero bits of extensibility is the right amount of extensibility, simply based on what I know about the history of bad engineering. However, I will say that my thinking, at least, has gone from unlimited permissionless definition of signals (the SPUD prototype, which was expressly experimental) to highly restricted definition of signals (PLUS as described in the charter) to restricted definition of signals with severely limited header / codepoint space, to address privacy as well as overhead concerns. This implies a tradeoff in the ability to fix things we got wrong later, of course.

> 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).

There appears to us to exist a useful set of signals that are transport-agnostic, the minimal set of which we hope to have a full description of (with bits, yay!!) shortly, as in my message to Eliot.

> 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.

As would I. I am frankly a little baffled as to who you think is proposing this interpretation.

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

As noted, I'm convinced the threat posed by coercion attack is very real, today. I still don't buy the assertion that PLUS expands this surface.