Re: Proposed Statement on "HTTPS everywhere for the IETF"

Niels Dettenbach <> Fri, 05 June 2015 08:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 94E6D1B2DF0 for <>; Fri, 5 Jun 2015 01:54:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.611
X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mZcJUkXB0cNB for <>; Fri, 5 Jun 2015 01:54:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D1C581B2DFC for <>; Fri, 5 Jun 2015 01:54:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=x; h=Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:To:From; bh=tpHaQvs3WfaOt0fYkIQdqGAmv2xBGQJj3iCTZylOpj0=; b=WUcYH0eqi3wbAATBgP5B6jJh5iyASe2+3gbnjBVyCEwRy0p0Czfe1uJ8+8knI08iDvGUOx9yFA5GEmTylK24wyqED4oSxubScrxLe51UjeMmzLrnrNUi1++nqAWgcJKNZluom3YPYnBZIdSr6XdWHiOChtwtjANX+9ol91LokpY=;
Received: from ([] helo=localhost) by with esmtp ( PostHamster 4.84) (envelope-from <>) id 1Z0nON-00018n-22 for; Fri, 05 Jun 2015 10:54:19 +0200
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F9MC55gzuXL6 for <>; Fri, 5 Jun 2015 10:54:18 +0200 (CEST)
Received: from ([] helo=gongo.localnet) by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) ( PostHamster 4.84) (envelope-from <>) id 1Z0nOM-0003Sr-PK for; Fri, 05 Jun 2015 10:54:18 +0200
From: Niels Dettenbach <>
Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"
Date: Fri, 05 Jun 2015 10:54:11 +0200
Message-ID: <4421169.2LipD28Tao@gongo>
Organization: Syndicat IT&Internet
User-Agent: KMail/4.14.6 (Linux/4.0.1-niels; KDE/4.14.7; x86_64; ; )
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3195960.ph52lKROrk"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Jun 2015 08:54:23 -0000

Am Donnerstag, 4. Juni 2015, 13:57:24 schrieb Roy T. Fielding:
> TLS does not provide privacy.  What it does is disable anonymous access to
> ensure authority. It changes access patterns away from decentralized
> caching to more centralized authority control. That is the opposite of
> privacy.  TLS is desirable for access to account-based services wherein
> anonymity is not a concern (and usually not even allowed).  TLS is NOT
> desirable for access to public information, except in that it provides an
> ephemeral form of message integrity that is a weak replacement for content
> integrity.
i remember and know several scenarios where providers (mainly in the middle 
east and africa, where bandwidth is still "expensive") still are using large 
scale HTTP caching (wie build a few of it in the past) - to "save bandwidth" 
(costs) and/or improve "surf performance" from their view. 

HTTPS stuff isn't "usually" cached (except they try to break it by faking all 
SSL by their own (MitM) "working" certificate, which is afaik less the case in 
provider networks). 

This means users have to use the outer side networks to get static HTTP docs 
in any case / for "each request" - these networks are still often not secured 
physically or logically (i.e. unencrypted satellite or microwave trunks or 
fiber over neighbour country territory - encryption still costs 
ressources/money here...) and so (at least) very easy to sniff by anyone with 
very small equipment - i.e. jouranlists, hobbyists and - of course - any kind 
of other guys within i.e. the same satellite footprint.

HTTPS brings centralization which leads to the opposite of "privacy" in such 
cases, but even if smaller networks are running caches this could make user 
tracking by third parties much more difficult.

To provide data integrity (by the entity [like the IETF] BYSELF and not any 
third party the user has to trust additionally and to read/check by hand each 
time using a browser session!) content signing would be much more helpful 
while it allows further access over HTTP caches or even mirrors. 

And not at least: caching and mirroring could hardly rise data availability - 
by redundancy and it is more difficult to block access to. See i.e. the former 
wikileaks mirror network working this way (and i remember how my collegue was 
tried pressed by german services / police to hand out access to the german 
wikileaks web domain some years ago...).

> If the IETF wants to improve privacy, it should work on protocols that
> provide anonymous access to signed artifacts (authentication of the
> content, not the connection) that is independent of the user's access
> mechanism.

I'm not a crypto geek, but for me something what allows i.e. using my own pgp 
public key to sign (HTTP) documents on request - integrated in browsers / web 
security standards or similiar, would be a helpful solution. 

F.i., PGP still needs improvements in the possibilities of (decentralized) 
trust handling and transparent, dynamic "security levels" (a user has to 
"decide" which entities he trust in which way on a still more transparent and 
easier to "manage" level) - but i think that a person or entity should be able 
to manage trust from his own view onto it - and not mainly/only single others 
(or a complete branche of as in HTTPS/x509 the case in practice). The PGP 
principle is the nearest to that att.

many thanks,

 Niels Dettenbach
 Syndicat IT & Internet