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

Stephen Farrell <> Sat, 30 July 2016 12:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 780A212D8BD for <>; Sat, 30 Jul 2016 05:14:19 -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 ThERiMXtW--v for <>; Sat, 30 Jul 2016 05:14:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2D11B12D694 for <>; Sat, 30 Jul 2016 05:14:18 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id BBA11BE4D; Sat, 30 Jul 2016 13:14:16 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UYDviq7sapqq; Sat, 30 Jul 2016 13:14:15 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id E593DBE33; Sat, 30 Jul 2016 13:14:14 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1469880855; bh=O85+6v9B6p4SSM8pLCBGAGVVcgWbPQXsI3hM9EdJyzM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=d+fjRe1NOnZk64PriLvl4z//UNQn6210dvVR9Ym4lr9s0JkXfYm5kGxQuWxpIvFY0 ZJmxlJxALx0i4JcdGzH78o0IcBjQG7Vf4YSi311QxJYXfrCNTAECwl0ccsfDRMu6Tp 684UdZFp192a0HX5VApCn0Z8RwbsMtV8Nh+UMdAE=
To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= <>
References: <> <> <> <> <> <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Sat, 30 Jul 2016 13:14:14 +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="------------ms050606000503020200040808"
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: Sat, 30 Jul 2016 12:14:19 -0000


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.