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, =?UTF-8?Q?Mirja_K=c3=bchlewind?= <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
>