Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks
Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 31 July 2016 16:03 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 9465512B046 for <spud@ietfa.amsl.com>; Sun, 31 Jul 2016 09:03:26 -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 mK_1K9AJaaoS for <spud@ietfa.amsl.com>; Sun, 31 Jul 2016 09:03:23 -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 E86FC12B015 for <spud@ietf.org>; Sun, 31 Jul 2016 09:03:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 66D0FBE56; Sun, 31 Jul 2016 17:03:21 +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 9Rzi2xbe-TaV; Sun, 31 Jul 2016 17:03:19 +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 C3F3DBE49; Sun, 31 Jul 2016 17:03:18 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1469980999; bh=oyiuf8yCjoCuv+Mi4rwtvLQr9zI2IzYv6Z6rFIV69M8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=IY5HgJsGrZTdERs0MYcKEyEbSkx1ZrRSpTIQX6RO3ZJ1wKDpMOFTB9k5qxAZlS4r6 zS+i3A11Xb2/27GlpUN6SbfA7aM7j70A7qQ2lgUybxB2vO6/+IgH+Txs5ifqUpQGKG U1UwK5q+ojiHfWf4gPrNQGcpbJvMC4QF3Mn6AsYg=
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
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>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <92b31df8-f557-a935-a3d8-1f7bf7ee8689@cs.tcd.ie>
Date: Sun, 31 Jul 2016 17:03:18 +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: <F7541B2E-86C2-49C6-B616-BDCC567CDAFC@lurchi.franken.de>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms040504080604090700060903"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/0oebM2h_bS50aH7jOIVxMSMULMw>
Cc: Brian Trammell <ietf@trammell.ch>, privsec-program@iab.org, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, spud <spud@ietf.org>
Subject: Re: [Spud] [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 16:03:26 -0000
On 31/07/16 16:45, Michael Tuexen wrote: > On 31 Jul 2016, at 16:05, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: >> >> >> Hiya, >> >> On 31/07/16 13:57, Mirja Kühlewind wrote: >>> Hi Stephen, >>> >>> yes, I believe that the proposed mechanisms are needed (in the first >>> place to address the ossification problem we see in transport - to >>> phrase it at a light level) and yes, I believe that the proposed >>> approaches have the potential to improve but at least doesn’t degrade >>> the situation in general but also the privacy situation that we have >>> today in the Internet. If I wouldn’t believe that, I wouldn’t propose >>> it. >>> >>> The technical basis for this believe (regarding privacy) is that we >>> propose a mechanism for integrity checking that is stronger than what >>> we have today in transport and therefore makes mangling as least >>> detectable. Further, I believe that only a cooperative approach will >>> enable large-scale encrypting (that includes transport headers) >>> because otherwise operators may be incentivized to block traffic, and >>> in this sense standardization of a mechanism for middlebox >>> communication would draw a much clearer line about what we as a >>> community deem acceptable and what not, instead of declaring all >>> in-network functions other than routing as evil. >>> >>> I intentionally used the word ‚believe‘ here several times because as >>> stated in my previous mail we just have probably very different >>> starting points. I do think some parts of our discussion involved >>> technical questions, and I hope I could clarify some points. However, >>> other parts of the discussion are naturally more vague because we >>> both don’t know the future. However, in this sense these ‚first >>> principles‘, as I believe you called them below, are purely what >>> people believe. But, please note that one of these ‚first principles‘ >>> is that we in transport see a problem with the ossification today, >>> and PLUS is foremost a proposal to address this problem (by enabling >>> encryption). Given this, I don’t really understand what your comment >>> about the form of the discussion is below. >> >> Let me try to clarify a couple of important places where my beliefs >> and yours don't seem to co-incide: >> >> - I'm not sure the ossification issue is as-it-was 3 years ago, >> given QUIC, and to some extent h2 and TLS1.3, but also due to >> the much increased deployment of TLS. Given such changes, it >> is not at all clear to me that a generic approach (like PLUS >> attempts) is best. > Hi Stephen, > > so do you mean future transport protocols (running over UDP) should > define their own protocol specific way of exposing information, > similar to the way QUIC does it? > That would require constant evolution of middleboxes (NAT, firewalls). > > Or are you suggesting that future transport protocols should just > use the framing of QUIC (for the unencrypted part) and reuse > the (hopefully) upcoming QUIC support of middleboxes? I didn't mean either. What I meant was that perhaps the analysis that lead to the conclusions about ossification of the transport layer needs to be re-done now, give the increase in use of TLS and given QIUC is now highly likely to be an IETF WG. (That's a similar question to asking if PLUS is OBE, which I think I asked of Brian.) IIUC the IAB w/s that sorta lead to SPUD then PLUS happened before QUIC was mooted as work in the IETF and before many services had switched from port 80 to 443. S. > > Best regards > Michael >> - 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. >> >> What I meant when referring to first principles was being explicit >> in how we're arguing based our these starting points (or beliefs). >> >> My perception of the argument (in this thread and the BoF) is that >> it is harder because the proponents of PLUS were assuming sharted >> beliefs/starting points when responding to folks who have very >> different starting assumptions. >> >> So for example, I don't think I've seen any of the PLUS proponents >> directly provide arguments as to why my concerns/beliefs above >> are unfounded. (I have seen assertions that they are unfounded but >> not arguments starting from assumptions with which I'd agree.) And >> my guess is that the proponents are not doing that because they >> think it was already done. (If a pointer to the SPUD archive is >> usable to answer this point, that's entirely fine.) >> >>> >>> However as you mentioned the BoF belong, I actually also have a >>> comment on the form of discussion: this activity is on-going for more >>> than one year. We mainly worked during this time on addressing >>> security questions that were raised at the spud BoF. Based on one >>> request on the mailing before the PLUS BoF we explained how we >>> address privacy concerns and how we think this makes the current >>> situation at least not worse and probably better. We did not get only >>> further feedback on mailing list assuming that our proposal is >>> acceptable. And there was no future discussion about any privacy and >>> security aspects on the list before the BoF. I would really >>> appreciate if people could constructively help us to find a solution >>> to address the ossification problem in transport while maintain or >>> improving the privacy situation we have today, instead of just >>> blocking new work. >> >> Yeah, that's fair. It is of course hard to get input from folks >> who are worried that the work as envisaged inevitably leads to a >> bad outcome. (So e.g. I'm not subscribed to the SPUD list and am >> not sure I'd have time and the energy to be on there constantly >> trying to drag you back to 1st principles;-) >> >> Cheers, >> S. >> >>> >>> Mirja >>> >>> >>> >>>> Am 30.07.2016 um 14:14 schrieb Stephen Farrell >>>> <stephen.farrell@cs.tcd.ie>: >>>> >>>> >>>> Hiya, >>>> >>>> I agree with your conclusion that we seem to have clearly set out >>>> where we disagree without so far changing one another's >>>> conclusions. So I only have one more thing to add for now, which is >>>> about the form of, and not the content of, the discussion. You >>>> said: >>>> >>>> On 30/07/16 12:07, Mirja Kühlewind wrote: >>>>> Enabling large scale encryption that is deployable is the goal >>>>> of PLUS. And this enables two things: increased security and >>>>> privacy, as well as transport evolution. For the first goal we >>>>> need encryption and maintain the status quo (regarding network >>>>> manageability), while for the second part, we envision the >>>>> development and use of new transports that enable new services. >>>>> Not having a tool to also enable some innovation in the network >>>>> to support these services, archives the goal only half way. >>>> >>>> I'm fine with and fully accept the first sentence. >>>> >>>> The rest of that paragraph however seems to me to beg the >>>> question, that is, it assumes that a deployed PLUS-solution will be >>>> an overall good, when it is exactly that that I and others wish to >>>> question. I do think this is an issue in this discussion and was in >>>> the BoF - the proponents, being convinced that the solution is >>>> needed, assume that the solution is needed when answering those who >>>> are questioning whether we'd be better or worse off should PLUS be >>>> developed further. >>>> >>>> That's probably natural given folks have been working on SPUD/PLUS >>>> for some time, but it seems to me to hinder discussion with folks >>>> like me who are far from convinced that the envisaged solution is >>>> at all desirable. So my apologies for trying to drag you back to >>>> what you likely consider first principles you probably figured were >>>> done with a couple of years ago, but I think that's actually fair >>>> and to be expected when one has a BoF of this kind. >>>> >>>> Cheers, S. >>>> >>>> >>>>> >>>>>>> >>>> >>> >>> _______________________________________________ Privsec-program >>> mailing list Privsec-program@iab.org >>> https://www.iab.org/mailman/listinfo/privsec-program >>> >> >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud >
- 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