Re: [Ideas] [lisp] WG Review: IDentity Enabled Networks (ideas)

John C Klensin <> Sat, 04 November 2017 21:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 490D413FB06; Sat, 4 Nov 2017 14:37:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K6xc3ak-BtB0; Sat, 4 Nov 2017 14:37:27 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 12AA313FADA; Sat, 4 Nov 2017 14:37:26 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1eB67z-0005ws-Fk; Sat, 04 Nov 2017 17:37:19 -0400
Date: Sat, 04 Nov 2017 17:37:12 -0400
From: John C Klensin <>
To: Tom Herbert <>, Toerless Eckert <>
cc:, " list" <>, Christian Huitema <>, Dino Farinacci <>,
Message-ID: <B6CAD3DCDB18980FA879E936@PSB>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [Ideas] [lisp] WG Review: IDentity Enabled Networks (ideas)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 04 Nov 2017 21:37:28 -0000

--On Saturday, November 4, 2017 09:34 -0700 Tom Herbert
<> wrote:

> A good example
> is turning up the TLS on the Internet; this eliminated the
> need to trust the network with our plaintext. 

And, for many people, replaces it with the need to trust
firewall and security appliance providers who have concluded
that they need to intercept and decrypt traffic in order to
identify malware and other undesirable traffic.   At least in
principle, one does get to choose which vendor to trust and does
know (by virtue of having to install special certificates) which
vendor or provider is being trusted, but those options may not
be meaningful for typical users.

I worry with that example and several others that the IETF is
not adequately distinguishing between "increasing privacy" or
"preventing mass surveillance" on the one hand and forcing users
into a "who do your trust" or even "who does someone trust on
your behalf" shell game on the other.