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

Stephen Farrell <> Sun, 31 July 2016 16:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9465512B046 for <>; Sun, 31 Jul 2016 09:03:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.588
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mK_1K9AJaaoS for <>; Sun, 31 Jul 2016 09:03:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E86FC12B015 for <>; Sun, 31 Jul 2016 09:03:22 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66D0FBE56; Sun, 31 Jul 2016 17:03:21 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9Rzi2xbe-TaV; Sun, 31 Jul 2016 17:03:19 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id C3F3DBE49; Sun, 31 Jul 2016 17:03:18 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; 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 <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
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: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040504080604090700060903"
Archived-At: <>
Cc: Brian Trammell <>,, =?UTF-8?Q?Mirja_K=c3=bchlewind?= <>, spud <>
Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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

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.


> 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
>>>> <>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 
>> _______________________________________________
>> Spud mailing list