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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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, he
must 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 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.

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]