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

From: Raphaël Durand <[email-masked]>
Date: Mon, 05 May 2014 13:28:18 +0200

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".
https://datatracker.ietf.org/doc/draft-loreto-httpbis-explicitly-auth-proxy/?include_text=1

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.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 5 May 2014 18:40:05 +0300

On May 5, 2014, at 2:28 PM, Raphaël Durand <[email-masked]> wrote:

> 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".
> 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.

Hi

I haven’t read the entire draft yet, but proxies don’t have to be the bottleneck. They are often deployed in conjunction with firewalls, and it is the firewalls that block connections trying to get around the proxy. 

IOW the proxy and firewall don’t have to be co-located.

Yoav

---

From: S Moonesamy <[email-masked]>
Date: Mon, 05 May 2014 09:50:15 -0700

Hi Raphaël,
At 04:28 05-05-2014, Raphaël Durand wrote:
>I've just read the draft 
>draft-loreto-httpbis-explicitly-auth-proxy, and 

In Section 3.1:

   "To help end users understand the reason why the proxy is offered (in
    other words, the benefits of having the proxy in the path)"

Section 6.1 of one of the drafts being referenced 
has some text about "Living with Interception".

I did not comment about the questions in your 
message as the authors are better placed to answer them.

>"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."

There was a problem in December 2013 about a 
certificate which had been "mis-issued".

I could not find any discussion about "pervasive 
monitoring" in the Security Considerations 
section.  Did the authors consider that?

BYW, I posted a request for feedback at 
http://www.ietf.org/mail-archive/web/perpass/current/msg01735.html 
It would help me if you (or anyone else) could 
comment on the perpass mailing list.

Regards,
S. Moonesamy

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 6 May 2014 11:27:18 +0000

Hi Raphael,

first let me clarify once again: https resources are not affected by the explicitly authenticated proxy
the draft only propose to proxy the http:// resources.

On May 5, 2014, at 2:28 PM, Raphaël Durand <[email-masked]<mailto:[email-masked]>> wrote:

So if an user doesn't trust the proxy, he must pass through anyway ?

No if the user does not trust the proxy (i.e. does not provide consent for proxing http:// uri resources)
his/her traffic won't pass thru the proxy.

and just to say once again: https:// will never pass thru the proxy!

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 ?

as described in the section http://tools.ietf.org/html/draft-loreto-httpbis-explicitly-auth-proxy-00#section-3.2
 (and in other part of the document)

   A consent SHOULD
   however be limited to the specific network access (such as APN or
   SSID) and may be limited to a single connection to that access or
   limited in time.

i.e.  binding the proxy to a specific access

"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).

of course Could  be a local CA, but that does not work in airports, hotells….
Please note that the proxy is NOT automatically trusted based on CA,
the user has to explicitly provide consent (i.e. trusting the proxy) even if it has a cert signed by a trusted CA.

"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.

based on what we have described in the document a Client will never send an https:// resource thru a proxy

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 flawless and 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.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 5 May 2014 12:15:52 -0400 (EDT)

> First, it has to be "opt-in" not "opt-out" (it's called an "explicit auth proxy isn't it ?")

It refers to the user having accepted to proxy for everything and than
explicitely excluding something. So I don't have a problem with that
specific toggle - I do, like you,  have a problem with the entire document.

> "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."
> 

I fully agree.

> No they are not, there is a third-party proxy between them. The user do not operate it, so he can't trust it.

Indeed, and it further interferes and breaks out-of-band key validation,
such as TLSA/DNSSEC. So a protocol modification is completely useless,
as the application needs to turn off so many security features, it might
as well take the certificate check/override into the application as
well.

I must say, it is becoming rather tiring to see new incantations of
protocol modifications to account for "legalised MITM attacks". How
many times do we have to repeat that is a problem to be solved at the
application and/or OS level and not at the protocol level?

We have enough problems keeping our protocols secure without adding
dangerous protocol-based legalised attack modes into our protocols.

I am strongly against in-band MITM protocol modifications as specified
by this draft, its precursor drafts, and the inevitable follow up drafts.

Take your legalised enterprise MITM ideas to the OS and browser vendors.

Paul

---

From: Raphaël Durand <[email-masked]>
Date: Tue, 06 May 2014 21:49:30 +0200

Hello Salavatore.

> the draft only propose to proxy the http:// resources.
But one of the aim of HTTP2 is to make TLS 1.2 (or greater) mandatory,
the same way HTTPS does.
Add to this that most browsers have skipped the http or https part of an
URI, what will be the difference between http and https ?

In my opinion, with HTTP2 and mandatory encryption, HTTPS will no longer
exist. (except maybe for the handling of the X.509 trust model)
We have to deal all the encrypted flow in the same way. Any exception
would be fatal.

Best regards.
Raphaël Durand