Trust and provacy problems with draft-loreto-httpbis-explicitly-auth-proxy

Raphaël Durand <> Mon, 05 May 2014 11:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 34D9A1A02D9 for <>; Mon, 5 May 2014 04:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.3
X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ghQoOWmNPCR6 for <>; Mon, 5 May 2014 04:28:33 -0700 (PDT)
Received: from ( [IPv6:2001:4b98:c:538::196]) by (Postfix) with ESMTP id 11EE31A02D2 for <>; Mon, 5 May 2014 04:28:32 -0700 (PDT)
Received: from [IPv6:2a01:6600:8080:5600:d1c8:d497:b6f4:2a43] (unknown [IPv6:2a01:6600:8080:5600:d1c8:d497:b6f4:2a43]) (Authenticated sender: by (Postfix) with ESMTPSA id 82726172090 for <>; Mon, 5 May 2014 13:28:27 +0200 (CEST)
Message-ID: <>
Date: Mon, 05 May 2014 13:28:18 +0200
From: =?ISO-8859-1?Q?Rapha=EBl_Durand?= <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
Subject: Trust and provacy problems with draft-loreto-httpbis-explicitly-auth-proxy
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T82KFOUJbMUcvMoRKQAgjKhLUfQ8GqCbs"
X-Mailman-Approved-At: Mon, 05 May 2014 08:13:37 -0700
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: Mon, 05 May 2014 11:30:00 -0000

I've just read the draft draft-loreto-httpbis-explicitly-auth-proxy, and
I see a lot of trust and privacy problem in this "Explicit auth proxy".

The first problem is in the "opt-out" section (3.3).
First, it has to be "opt-in" not "opt-out" (it's called an "explicit
auth proxy isn't it ?")
Second, in order to be efficent, a proxy have to be a bottleneck, so
user can't get around it.
How can you implement the 3.3 scheme ? Does the proxy becomes transparent ?
So if an user doesn't trust the proxy, hemust pass through anyway ?

The other problem concern the trust model using CA certificates as
described in the 3.1 section.
What sort of certificate need theses proxies ? Does they need a wildcard
for the entiere Internet ?
//"To ensure the trustfulness of proxies, certification authorities
validation procedure for issuing proxy certificates should be more
rigorous than for issuing normal certificates and may also include
technical details and processes relevant for the security assurance.//"/

No, public CA must not sign these certificates. Proxies certificates
must be signed by a local CA explicitly trusted by the user.
(here and only here must be the explicit agreement).

/"//6. Security Considerations//
//"Those resources are protected end-to- end between user agent and
origin server as usual."/

No they are not, there is a third-party proxy between them. The user do
not operate it, so he can't trust it.
//"Users should also be made aware that the proxy has visibility to the
actual content they exchange with Web servers, including personal and
sensitive information."/
That's the point, and that why HTTP2 must be flawless. Because the
average user is never aware of security concern, IETF standards and
softwares based on them must to be flawlessand uncompromising.

Such systems was deployed in Lybia and Syria to trap opponents and kill
them (or worse).We should not standardize a method used as a weapon of
war by some governments.
The strength of a chain depends on its weakest link, do not
intentionally add weak links as these proxies.
Such proxies must not exist.The end to end encryption must not be
intercepted or compromised.

Best regards.
Raphaël Durand.