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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sat, 06 August 2016 12:38 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 5589B12B056 for <spud@ietfa.amsl.com>; Sat, 6 Aug 2016 05:38:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.648
X-Spam-Level:
X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, 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 v79qCpwTs_rH for <spud@ietfa.amsl.com>; Sat, 6 Aug 2016 05:38:40 -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 890B612B02E for <spud@ietf.org>; Sat, 6 Aug 2016 05:38:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 37BDDC0C3; Sat, 6 Aug 2016 13:38:39 +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 9F-TGx_DDfZ1; Sat, 6 Aug 2016 13:38:37 +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 13B92C09F; Sat, 6 Aug 2016 13:38:37 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1470487117; bh=QR9q8b7KMRLt7K1DF0dQWGl3ujwtvRTZvd6PG1QdKnc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=kgy8gCnLKs451f7DyVbOjbBCUQ9/0Za+SsS6+26VswuQTLW0U4rUptW5bFi6ubdAq YOlk+QCfUVgklmwccgxwPPZtyeeoFLrKN1OOTY4MJ6FyTPFAb7Rf1Ohi2EPRm+IvLM +hWySkNOVbP7/IfCMpjSJCo9Dan0O9mmjr8yqZn4=
To: Kyle Rose <krose@krose.org>
References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <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> <CAJU8_nWgdFNAKwegm9yXKcFB3BTkGeEQBPm3H4bY8JrWtTyXrQ@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <fd9d6567-6dbc-3044-7fb2-acaa560de401@cs.tcd.ie>
Date: Sat, 6 Aug 2016 13:38:36 +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: <CAJU8_nWgdFNAKwegm9yXKcFB3BTkGeEQBPm3H4bY8JrWtTyXrQ@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010308040603070303000505"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/bJtuAHZtGRNIBMc1V-JQupv1vZI>
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: Sat, 06 Aug 2016 12:38:42 -0000

Hi Kyle,

Again, sorry for the slow response. But we're likely evens on that:-)

On 03/08/16 12:00, Kyle Rose wrote:
> 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.

FWIW, I never agree that privacy is hopeless.

And even if it, in some sense, were, I firmly believe that we can
choose to make the Internet worse wrt privacy or to not do that.

So even if we cannot "solve" the "privacy problem," there is still
an onus on us (as good engineers) to not make that worse and to define
tooling that would allow folks to make things better should they later
choose to deploy those tools. (That last has to be done quite
selectively though, only after some tool looks like it might get at
least some real traction, as otherwise we enter the realm of speculative
research and not engineering.)

IOW - it is not hopeless and the sky is not falling:-)

Also - I'm not sure what you mean by "routing layers" nor how that
maps to the transport issues SPUD/PLUS is trying to address.

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

Yes, that and many other abominations could theoretically be attempted.

In that and many cases though the other endpoint would not (in general)
know of the silly addressing scheme. If we standardise such, then all
endpoints know of the silliness and the situation is worse.

I'm also not sure that coercion is the right term for this part of the
problem. At least as I envisage things, if a middlebox can ever add a
standardised extensible value to the flow, then we are likely to run
into these issues. It's very unclear to me that SPUD/PLUS can work and
not allow such addition whilst also not introducing new round-trips.
But we'll need to wait and see what the PLUS proponents actually
propose before we can really analyse that.

Cheers,
S.

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