- From: Salvatore Loreto <salvatore.loreto@ericsson.com>
- Date: Tue, 18 Feb 2014 10:32:28 +0000
- To: Fabian Keil <freebsd-listen@fabiankeil.de>
- CC: "<ietf-http-wg@w3.org>" <ietf-http-wg@w3.org>
Hi Fabian thanks for the comments see in line On Feb 18, 2014, at 12:17 PM, Fabian Keil <freebsd-listen@fabiankeil.de> wrote: > 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. fair enough, I will use the suggested terminology in the next version > > 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? it is supposed to opt out… only use h2 ALPN tag for all the traffic > > | 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. yes it sound a reasonable thing to do > > 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. you are right, it is not explicitly there but it will switch to only use h2 ALPN tag for all the traffic /Salvatore > > Fabian
Received on Tuesday, 18 February 2014 10:32:53 UTC