Re: new version trusted-proxy20 draft

Salvatore Loreto <salvatore.loreto@ericsson.com> wrote:

> we have submitted a new version of the "Explicit Trusted Proxy in HTTP/2.0" draft
[...]
> Comments, suggestion and feedback are really welcome

From 1. Introduction:
| HTTPS tunnels, while speeding up the deployment, makes it difficult
| for a forward proxy and other intermediaries to be used to allow
| caching, to provide anonymity to a User-Agent, or to provide security
| by using an application-layer firewall to inspect the HTTP traffic on
| behalf of the User-Agent (e.g. to protect it against cross-site
| scripting attacks).

I'd prefer "provide anonymity" and "provide security" to be reworded
to something less optimistic like "enhance privacy" and "enhance security".
Expecting a proxy to provide anonymity and/or security doesn't seem
realistic to me.

Even the mentioned cross-site scripting "protection" is unlikely to
work for all attacks and all clients.

From "3.1. Proxy certificate":
| As the user needs to have high trust in the Proxy, the validation
| procedure for proxy certificates should be more rigorous than for
| ordinary SSL certificates. All proxy certificates should therefore
| be Extended Validation (EV) SSL Certificates.

I don't think the text should promote EV certificates as being
more trustworthy than "ordinary" certificates.

From "3.1.1. TLS Handshake with Proxy certificate":

| When a (TLS and HTTP) User-Agent receives a Server Certificate
| message, it checks whether the certificate contains an Extended Key
| Usage extension and if so whether the "proxyAuthentication" key
| purpose id is included.  If it is included, the User-Agent concludes
| that the certificate belongs to a proxy.  It then verifies that the
| proxy certificate is a valid EV certificate.  The user-agent then
| SHOULD secure user consent.

What is the user-agent supposed to do if it's not a EV certificate
or an invalid EV certificate?

| When the user has given consent to the use of a proxy, the User-Agent
| SHOULD store this consent so that the user does not have to give
| consent for each new TLS connection involving the proxy.  The consent
| SHOULD be limited to the specific access and MAY be limited to a
| single connection to that access or limited in time. 

I'd prefer to be able to limit consent to certain websites.

Section "3.1.2. Opt Out" doesn't mention how the proxy opts
out of serving a user who didn't consent to the interception.

Fabian