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

Mirja Kühlewind <> Sun, 31 July 2016 12:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0666012D192 for <>; Sun, 31 Jul 2016 05:57:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vHJkABSm4oiE for <>; Sun, 31 Jul 2016 05:57:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C2D4E12D159 for <>; Sun, 31 Jul 2016 05:57:11 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63932D9315; Sun, 31 Jul 2016 14:57:09 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id 6jXJ49xA68T9; Sun, 31 Jul 2016 14:57:09 +0200 (MEST)
Received: from [] ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by (Postfix) with ESMTPSA id 181A8D930E; Sun, 31 Jul 2016 14:57:09 +0200 (MEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: =?utf-8?Q?Mirja_K=C3=BChlewind?= <>
In-Reply-To: <>
Date: Sun, 31 Jul 2016 14:57:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: Stephen Farrell <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: Brian Trammell <>,, 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 12:57:14 -0000

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. 

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.


> 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.