Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Sun, 31 July 2016 15:45 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 05A1512D0F8 for <spud@ietfa.amsl.com>; Sun, 31 Jul 2016 08:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.888
X-Spam-Level:
X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001] autolearn=unavailable autolearn_force=no
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 LMziXWehTpI3 for <spud@ietfa.amsl.com>; Sun, 31 Jul 2016 08:45:46 -0700 (PDT)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D274712B036 for <spud@ietf.org>; Sun, 31 Jul 2016 08:45:45 -0700 (PDT)
Received: from [192.168.1.7] (p4FE312A4.dip0.t-ipconnect.de [79.227.18.164]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id A52A1721E280D; Sun, 31 Jul 2016 17:45:41 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <6a61c305-c1f6-d14d-d0c4-d9809cfb5f78@cs.tcd.ie>
Date: Sun, 31 Jul 2016 17:45:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F7541B2E-86C2-49C6-B616-BDCC567CDAFC@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>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/awPw5F84MdnfADXotaSvGkGqaPo>
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 15:45:50 -0000

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?

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