Re: [perpass] perens-perpass-appropriate-response-01

Martin Millnert <> Wed, 04 December 2013 10:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5A00C1AE059; Wed, 4 Dec 2013 02:07:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.693
X-Spam-Status: No, score=0.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T3dVEaH9k7Qe; Wed, 4 Dec 2013 02:07:26 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id B6AA41AE067; Wed, 4 Dec 2013 02:07:25 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id C1241B0; Wed, 4 Dec 2013 11:10:01 +0100 (CET)
Message-ID: <>
From: Martin Millnert <>
To: Bruce Perens <>
Date: Wed, 04 Dec 2013 11:07:20 +0100
In-Reply-To: <>
References: <> <> <>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-xntkbTz+gwAJ0Uez//W5"
X-Mailer: Evolution 3.4.4-3
Mime-Version: 1.0
Subject: Re: [perpass] perens-perpass-appropriate-response-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Dec 2013 10:07:28 -0000

Hi Bruce,

On Tue, 2013-12-03 at 17:25 -0800, Bruce Perens wrote:
> I have written a reply to draft-farrell-perpass-attack-00
> Please read it at
> The reply is _not_ in the form of an Internet Draft, because it's
> political discourse.

The only technical argument that I found with any relevance and merit is
that proper encryption of every HTTP operation in HTTP2 would make
transparent proxying and caching without the end-users knowledge

I'd assume that has been discussed on HTTP-WG already, but in terms of
perpass, that is a feature/bug which is of much much lesser importance
than the dangers of pervasive surveillance.

HTTP2 with encryption will not make CDNs impossible, or even really
change them in any meaningful way since HTTP1/2 is merely the transport.
(CDN redirection is done using DNS or HTTP headers/payload.)
Nor will it make the enterprise with managed clients' content filtering
appliances impossible.
Uses, legitimate or not, of transparent proxy/caching will be hurt,
AFAIK, and that's the only technical issue worth debating IMHO.
Personally I'm ok with that.  Even so, there are ways to signal
existence of caching proxies which can be extended to cover some of
these areas, by moving to non-transparent proxying.

For the other, mostly technical, arguments put forth by you:

  p3. A sovereign entity may outlaw technical protocol X:
  It wouldn't be a sovereign entity if it couldn't.  It could outlaw Pi
= 3.1459... for all I care.  Point is we should not let a single
Sovereign Entity outlaw the correct definition of Pi, for the rest of
us. It is precisely within IETF's jurisdiction to define our global
common Internet communication protocols.  If a single backwards
Sovereign Entity held veto power over this we would be much poorer
today. Instead the backwards sovereign entities will have to live
without these protocols, which is what they in their sovereignty decided
anyway, so everybody would be happy...

  p3. Unnecessary to encrypt static content:
It has been quite clearly shown that precisely this traffic path on the
web is an attack vector against a host.  It makes perfect sense to
secure that attack vector.

  p3. Pervasive surveillance glass half empty/half full (Technical
solutions do not lead to justice):
  Prefer half full.

  p4. Encryption use a lot of power:
It is strictly true that encryption spends more CPU cycles - how much
could be estimated - I would expect single-digit % extra cycles, with
proper stack and browser implementations.
  Spending these single-digit extra cycles does not increase power usage
linearly, due to CPU caching and more.  I personally guess the true
power usage delta is less than 0.1% for ordinary web browsing.

  p5. IETF is forbidden from doing any work if there is a related
political debate on a topic:

I do agree technical society should work closer with political society,
and I think this is happening increasingly.
It does not imply that a global political absolute consensus is required
for every Internet protocol update, because that will never work, and
will revert us to the stone-age.

Let the IETF improve what they can and at the same time meet politicians
half way.