Re: [Spud] Extensibility considered harmful? was Re: [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks
Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 01 August 2016 20:55 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 A372212DAF4 for <spud@ietfa.amsl.com>; Mon, 1 Aug 2016 13:55:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.588
X-Spam-Level:
X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 0qZUz2YLqjk8 for <spud@ietfa.amsl.com>; Mon, 1 Aug 2016 13:55:52 -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 3D06A12D8AB for <spud@ietf.org>; Mon, 1 Aug 2016 13:55:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 47076BE3E; Mon, 1 Aug 2016 21:55:49 +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 MrnUIxB9ahFF; Mon, 1 Aug 2016 21:55:47 +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 3524CBE39; Mon, 1 Aug 2016 21:55:47 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1470084947; bh=KZ3CoB9VQ6+3VzOPwicAIMexuXDcfJO6AYB0MUowxh0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=09rpKU4/r/Qth6qz7OUKaeFr8eT559bnePU32G2P+B/x195OEKvKMcnSH7ghnkyxk wA5hlBcVrr/mirpj18ODOGvFsoQXE1NUqg0cQ0Gmvoeo3+76wA8AYJ7ipyxUhI+8o+ xSoB1LmlEDotLfSL7GSYQ+XsqOv/H+Ym1zcRblOM=
To: Ted Hardie <ted.ietf@gmail.com>
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>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <5113d019-2405-fba0-0868-04a05ccce3f1@cs.tcd.ie>
Date: Mon, 01 Aug 2016 21:55:46 +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: <CA+9kkMB+j=My1i2Ygyz1VaO+ZjgtPr-SjoEKhcdve8gw-vq0Jw@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030709050205010304080700"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/q3CUksdjSjpRfKQuRNh_hVXnmV8>
Cc: Brian Trammell <ietf@trammell.ch>, spud <spud@ietf.org>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
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: Mon, 01 Aug 2016 20:55:54 -0000
Hiya, On 01/08/16 19:56, Ted Hardie wrote: > On Sun, Jul 31, 2016 at 6:01 PM, Stephen Farrell < > >> >> IMO that case has not been made to the point where I would >> consider it justifies privacy downsides. IOW, while I am of >> course in favour of endpoints being able to signal to one >> another without middlebox interference, I am not at all on >> side with transport header integrity being counted as a major >> win in the analysis of PLUS, if that "win" inherently requires >> a significant privacy cost. (And I am clearly happy to endlessly >> repeat myself that in this particular case: >> >> extensibility == privacy unfriendly >> >> > Stephen, someone naively coming across this statement in the record will > think you mean that any extensibility is privacy unfriendly. Obviously, > you have championed the ability to shift cryptographic algorithms as needs > change, which requires extensibility of specific forms. Lots of other > work requires extensibility to be useful at all (imagine if the tag space > of the web had been frozen in 1993). > > I should greatly appreciate you reformulating this into something that > actually matches your meaning. That would likely be useful; this is not. Sorry if there was context lacking and happy to try elucidate further (and please do feel free to help improve my description of the issue)... In the specific case of exposing higher layer information about well protected (e.g. encrypted) traffic to lower layers, (whether via an interface from the higher layer, or via addition by the lower layers) I believe any extensible mechanism for that kind of interface severely risks being extremely privacy unfriendly. And the transport layer may be the worst possible case of such an extensible higher/lower layer interaction as it by definition spans the full "width" of the network. I think the main reason is that there would be significant pressure and temptation to try support non-technical policies being enforced at one place in the network based on information provided at another. In this case, by "non-technical," I mean any information not absolutely necessary for the correct operation of the lower layer. That's a term and definition I'm sure could be improved, and I'm also sure there could be borderline cases. But there would immediately also be cases that are nowhere near any border... such policies would almost certainly demand methods to expose personally identifying information or identifiers that can be easily (re)identified as such. That would directly enable the kind of meta-data collection and tracking that the IETF has agreed is an attack in BCP188. (I assume here that no relevant lower layers "need" PII to operate correctly - if they do, they are probably broken:-) 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. While there do doubtlessly exist use-cases for such extensibility in this context that initially appear reasonable, the potential impact of the abuse cases, and my own opinion of their probability of occurrence being approx 1.0 at some place(s) and times on the big-I Internet for me very much outweighs any potential utility from non-abuse cases of this particular kind of extensibility. As an aside, I fully accept that folks arguing for non abuse-cases of extensibility are doing so with good intentions. I think this is just an unusual case where our normal ways of engineering extensibility are way more dangerous than usual. (*) In the case of the proposed charter at the BoF, the use of an IANA registry seems particularly unwise to me as in addition to being open to pressure to formally register privacy-unfriendly codepoints, any IANA-based scheme would also allow for squatting on codepoints, which we know can become a fait-accompli. I don't see any way in which IETF/IANA processes could resist the pressure to provide such "policy" support. I also cannot think of a non-IANA extensibility mechanism that could work here and not have the privacy downsides. And lastly, there is a significant difference here between existing non-standard methods for injecting the above kinds of information and a world in which we have standardised such extensibility. The status quo may allow for such injection but the full horror of the worst abuse-cases here would require that the abuse-case information flow from end-to-end unimpeded (or almost end-to-end) so reliably abusing that kind of information does I think require a standard. Hopefully that's clearer, (it's definitely longer;-) and again, I'd really welcome crisper and better text to describe these issues as I'm sure it's a discussion that will recur at other times and places. Cheers, S. (*) The "usual" dangers of extensibility are I guess complexity and loss of interoperability, exemplified in the current debate about TLS ciphersuite structure and TLS version intolerance. > > thanks, > > Ted >
- Re: [Spud] Extensibility considered harmful? was … Kyle Rose
- Re: [Spud] Extensibility considered harmful? was … Stephen Farrell
- Re: [Spud] Extensibility considered harmful? was … Stephen Farrell
- [Spud] Detecting and Defeating TCP/IP Hypercookie… Brian Trammell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Mirja Kühlewind
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephan Neuhaus
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell
- Re: [Spud] Extensibility considered harmful? was … Kyle Rose
- Re: [Spud] Extensibility considered harmful? was … Brian Trammell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Tom Herbert
- Re: [Spud] [Privsec-program] Detecting and Defeat… Eliot Lear
- Re: [Spud] [Privsec-program] Detecting and Defeat… Eliot Lear
- Re: [Spud] [Privsec-program] Detecting and Defeat… Christian Huitema
- Re: [Spud] Extensibility considered harmful? was … Stephen Farrell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Tom Herbert
- Re: [Spud] [Privsec-program] Detecting and Defeat… Christian Huitema
- Re: [Spud] [Privsec-program] Detecting and Defeat… Spencer Dawkins at IETF
- Re: [Spud] [Privsec-program] Detecting and Defeat… Tom Herbert
- Re: [Spud] [Privsec-program] Detecting and Defeat… Spencer Dawkins at IETF
- Re: [Spud] Extensibility considered harmful? was … Ted Hardie
- Re: [Spud] [Privsec-program] Detecting and Defeat… Tom Herbert
- Re: [Spud] [Privsec-program] Detecting and Defeat… Eliot Lear
- Re: [Spud] [Privsec-program] Detecting and Defeat… Tom Herbert
- Re: [Spud] [Privsec-program] Detecting and Defeat… Eliot Lear
- Re: [Spud] [Privsec-program] Detecting and Defeat… Eliot Lear
- Re: [Spud] [Privsec-program] Detecting and Defeat… Eliot Lear
- Re: [Spud] Extensibility considered harmful? was … Stephen Farrell
- [Spud] Extensibility considered harmful? was Re: … Brian Trammell
- Re: [Spud] Detecting and Defeating TCP/IP Hyperco… Tom Herbert
- Re: [Spud] [Privsec-program] Detecting and Defeat… Spencer Dawkins at IETF
- Re: [Spud] [Privsec-program] Detecting and Defeat… Michael Tuexen
- [Spud] Extensibility considered harmful? was Re: … Brian Trammell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell
- Re: [Spud] Detecting and Defeating TCP/IP Hyperco… Christian Huitema
- Re: [Spud] [Privsec-program] Detecting and Defeat… Michael Tuexen
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Eliot Lear
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Michael Tuexen
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Mirja Kühlewind
- Re: [Spud] [Privsec-program] Detecting and Defeat… Tom Herbert
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephan Neuhaus
- Re: [Spud] [Privsec-program] Detecting and Defeat… Tom Herbert
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Mirja Kühlewind
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Mirja Kühlewind
- Re: [Spud] [Privsec-program] Detecting and Defeat… Joe Touch
- Re: [Spud] [Privsec-program] Detecting and Defeat… Ted Hardie
- Re: [Spud] [Privsec-program] Detecting and Defeat… Ted Hardie
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell
- Re: [Spud] Detecting and Defeating TCP/IP Hyperco… Stephan Neuhaus
- Re: [Spud] Detecting and Defeating TCP/IP Hyperco… Tom Herbert
- Re: [Spud] Detecting and Defeating TCP/IP Hyperco… Brian Trammell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Brian Trammell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Mirja Kühlewind
- Re: [Spud] Detecting and Defeating TCP/IP Hyperco… Tom Herbert
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell
- Re: [Spud] [Privsec-program] Detecting and Defeat… Stephen Farrell