Re: new version trusted-proxy20 draft

Le Ven 14 février 2014 19:56, Salvatore Loreto a écrit :
> dear wg
>
> we have submitted a new version of the "Explicit Trusted Proxy in
> HTTP/2.0" draft

Thank you for the new draft!

One small remark:

EV won't fly on private networks, the network owner won't pay an external
semi-trusted CA for its internal users, it will deploy self-signed or
signed-by-internal PKI certificates (and that's better that way it limits
the number of signed-by-external-CA certs that can leak outside the org)

Anyway I feel there are too many different modes in the draft, could not
it be simplified with:

  A. web client sends direct request with h2 or h2clr ALPN protocolname
     → if it succeeds nothing more to do
     → web clients that do not want to help transparent caches MAY use h2
by default

  B. otherwise it receives a firewall hello with a proxy network location
    → it is not necessary at this stage to establish trust, trust is only
needed when you start talking to the proxy,
    → trust is not needed with the firewall since it has already proved
ability to block direct communication and that's all that matter from
the client POW
    → firewall http smarts need to be kept at minimum to avoid costly
interactions with the proxy

  C. Web client sends a new hello to the proxy network location, and
checks the certificate in the answer
    → if cert untrusted return to A but the web client may have to give up
on the network if the firewall insists

  D. Otherwise, establish TLS connexion with the proxy
    → after this point the web client MAY choose to use the proxy for
other connexions if it does not want to try direct before

  E. web client sends new request through the proxy TLS connexion (either
h2clr or CONNECT-like tunnel-in-a-tunnel for h2)

  F. If the requests succeeds we're finished

The following optional errors can be sent at any time by the proxy once
the TLS connexion is established
  1. ??A: rebalance: pac-like proxy info files with the list of preferred
proxies to use at this moment and sites that can be reached directly
  2. 511: portal → go authenticate or click through this location before
continuing
     a. do web clients need a separate re-auth code or will they be smart
enough to replay auth if they receive a new 511 to the same location
after a while? Question for web client people
     b. I assume the location needs to be https using the same kind of
cert as the proxy node
  3. ??B: downgrade → operator only allows h2clr to this site, downgrade
h2 to h2clr or go away (direct has already failed at this stage)
  4. 666: forbidden → proxy operator really does not want you to go there,
life sucks
  5. ??C: dns error → proxy can't find your site
  6. ??D: timeout   → web site does not answer

I assume that to avoid HOL problems the web client may have several
requests in fly so proxy errors must contain an identifier of the request
that triggered them.

Web clients can try another network or refuse the connexion at any time if
they don't like what the proxy told them.

Is this not sufficient to cover all cases? It lets proxy-adverse clients
try to avoid them as much as possible before falling back on proxies, and
describes a single generic mode instead of multiplying them. You need to
specify 4 proxy-specific error codes and nothing more (proxy can get by
without those codes but it results in silent hangs so it's better to be
explicit)

Regards,

-- 
Nicolas Mailhot

Received on Monday, 17 February 2014 15:12:28 UTC