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 ?
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 ?
(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.