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

Kyle Rose <krose@krose.org> Wed, 03 August 2016 11:00 UTC

Return-Path: <krose@krose.org>
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 D503712D1BE for <spud@ietfa.amsl.com>; Wed, 3 Aug 2016 04:00:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 P0wsgfo1rD_V for <spud@ietfa.amsl.com>; Wed, 3 Aug 2016 04:00:03 -0700 (PDT)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 1064712D12D for <spud@ietf.org>; Wed, 3 Aug 2016 04:00:03 -0700 (PDT)
Received: by mail-qt0-x22e.google.com with SMTP id w38so140034860qtb.0 for <spud@ietf.org>; Wed, 03 Aug 2016 04:00:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cjuBf36RkurnsDPHsv2kFAnYYGpnUrC0MgGiI5F1qFs=; b=nNcOYXTr2Pm/xQVvR21jfWpFT6vHUZ5NZXREXipio5vtVNMHWB6ITjmQA2sMidXIu5 5AX7NqtZXKZmZUrrBybrvIvDYeX05+y4jqkmYU3cDFq0yrNI6pTymbXk31uaiw04Mgxd eFxIDhyS32E/HrOpkQ3Q0EBOmEmpUglO+VlcY=
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; bh=cjuBf36RkurnsDPHsv2kFAnYYGpnUrC0MgGiI5F1qFs=; b=hqnjnSViq8N0HL6Tnh4dIaBRqiVlp+bGBLUegb9/EXHEuxvtTrk6ku/e1+1ZLv0CtX Rx1TkzLBcOAu/5ShMBCgZDTPBzhry5idZ0cx6NRameadE9c+Y3BnhuSEcQHEg5R/9HlY FXDBEYFmD2A8HvUU2Yo0HYt812xZnFhIk1Aryb9sG7DiwArRkhK76pqENzdfKbJiOjqI 4/5xnUh6FfsEwdiqF3F5Nuap403y7L4LymRn+rvrYIrq61KR9VlgN6MbRJZ86DEd/yZ7 o+XZTRV9OhgnaSR+72MioQ+Hp/pXd0EanSs1/Vo20lNMfytfzpnqlzWOCDN/gVhijHFt txUw==
X-Gm-Message-State: AEkoouuPaF5mWEzed0M0w/dWdEAuwQ9zIZ/R4kc3QHsb0MNM89BAWPa2Wxedx9tmw2/eG00bRwTXy23FfRTT6A==
X-Received: by 10.200.55.27 with SMTP id o27mr106700890qtb.85.1470222002036; Wed, 03 Aug 2016 04:00:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.94.70 with HTTP; Wed, 3 Aug 2016 04:00:01 -0700 (PDT)
X-Originating-IP: [2001:470:1f07:121:d866:7f9f:ae1:b38a]
In-Reply-To: <5113d019-2405-fba0-0868-04a05ccce3f1@cs.tcd.ie>
References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <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> <B018BDCD-64EF-4F86-9B0B-FA73EA63A5C9@trammell.ch> <b4a87191-0bb9-7c3a-9717-68ae6ef33406@cs.tcd.ie> <CA+9kkMB+j=My1i2Ygyz1VaO+ZjgtPr-SjoEKhcdve8gw-vq0Jw@mail.gmail.com> <5113d019-2405-fba0-0868-04a05ccce3f1@cs.tcd.ie>
From: Kyle Rose <krose@krose.org>
Date: Wed, 3 Aug 2016 07:00:01 -0400
Message-ID: <CAJU8_nWgdFNAKwegm9yXKcFB3BTkGeEQBPm3H4bY8JrWtTyXrQ@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary=001a113e6e5c2c3a72053928bcc0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/W2LdCfJGUYjzxgyAFG9WI2Oc3VY>
Cc: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>, Brian Trammell <ietf@trammell.ch>, Ted Hardie <ted.ietf@gmail.com>, =?UTF-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, spud <spud@ietf.org>
Subject: Re: [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: Wed, 03 Aug 2016 11:00:06 -0000

On Mon, Aug 1, 2016 at 4:55 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>;
wrote:

> But another and possibly even worse (ab)use case might signal that the
> person associated with a flow is a member of some set of people, for
> example, over-18, a member of the ruling party, or of some minority.
> The consequences of standardising that kind of extensibility in a way
> that could allow such "policy enforcement" at essentially any place
> on the Internet is for me supremely scary.
>

I've been thinking and having offline conversations about this for a few
days. (Sorry to lob a bomb and then disappear. Stupid work.)

Perhaps ironically, this argument has basically re-convinced me that
privacy at the routing layers on the public internet is hopeless.

If your threat model concerns itself with coercion over a single bit of
information, then the very architecture of the internet is completely
broken: a government can simply issue even addresses to over-18's and odd
addresses to under-18's. Enforce it at the ISPs and you're done.

Continuing this line of thought, with IPv6 it seems pointless to worry
about end-to-end survival of any metadata shorter than 64 bits (the host
ID), which leaves 2^31 identifiers per human should a government want to
enforce specific assignment of those addresses by ISPs. There's already far
too much space baked in at the IP layer for a threat model that includes
coercion of small amounts of metadata.

A good argument might start with, "Twenty years from now, perhaps the
internet will look a lot different than it does today." Which is something
I've said myself, based on conversations with you and Dave Plonka. But I
think we need lots more details on what that would actually look like to
justify vetoing all extensibility mechanisms from now until that day comes.
Worry doesn't seem sufficient justification given the implications of this
kind of threat model and the demonstrable usefulness of extensibility: the
architecture of a privacy-first internet needs to be fleshed out.

For instance, what would an internet without plaintext source addresses
look like? Without BCP38, what would we do to address (what are today
spoofing-based) DoS attacks? I'm sympathetic to architectural changes like
this, as from a security perspective the source address is simply a hint:
it's 128 bits that the sender can almost always lie about. But an actual
proposal is needed to know if an internet without them is even feasible.
And even if we confirm that this new internet is deployable, there's still
the whole problem of actually deploying it. If it requires starting from
scratch as IPv7 because it won't interoperate with v6, it's going to be
really hard to get adoption without using v4/v6 as a substrate, like TOR.
At which point we might as well return to the approach of running smaller
private internets over the public internet.

I think there still are some good arguments being made that exposing any
transport signaling to middle boxes creates further implicit ossification
around multipath that need to be explored further, but at this point I'm
unconvinced by the coercion argument given the internet we have.

Kyle