Re: HTTbis spec size, was: Rechartering HTTPbis

On Sat, Jan 28, 2012 at 02:09:36PM +0000, Poul-Henning Kamp wrote:
> >Many sites "route" by URI,
> >meaning the "/" is also part of the transport to some extent (eg:
> >route to static servers rather than application servers).
> 
> They're welcome to do so in the future as well, but it should be
> clearer for everybody involved that they are rounting based on
> the request content then.

Indeed.

> The reason I made the URI part of object-metadata, is that it
> may need security/privacy/integrity protection.

Yes, I know.

> >     4- payload         -> path, content-types, etc...
> >     3- session         -> cookies, user info, auth
> >     2- scrambling      -> TLS or whatever comes next
> >     1- transport       -> MUX, pipelining, keep-alive
> 
> I generally agree, but I'm not sure if 1&2 are above/below or side-by-side.
> 
> That question really boils down to if the Host: header is privacy
> protected or not.  This becomes a particularly intricate dance once
> anonymising proxies are involved.

Right now there is no privacy on the Host header since it's advertised in
clear text over TLS/SNI (and used as such at some sites to route to the
appropriate farm without having to decipher the stream). I would really
put the Host in the transport layer to avoid any of the current issues,
such as servers which believe this already works this way and trust the
connection instead of the request.

> If Host: should have privacy, then HTTPS, as we know it, where the
> entire TCP connection is encrypted, is the answer.
> 
> If Host: should not have privacy, in order to allow traffic directors,
> load-balancers and similar to dispatch secure traffic without terminating
> the crypto-session, then a payload-only SSL scheme would be preferable.

Payload + session, as cookies are used for many things but are sensitive.
I'd really like to have other session indications in the lower layers so
that we don't need to decipher SSL anymore to find the proper server in a
load-balanced farm. That's what's been discussed for IPv6 flow labels [1]
BTW and would avoid the current mess where load balancers are the single
non-scalable point where SSL has to be deciphered just for this. We could
have the transport carry a "public session ID" for instance or even simply
a "public session cookie".

Regards,
Willy

[1] http://tools.ietf.org/html/draft-carpenter-v6ops-label-balance-01

Received on Saturday, 28 January 2012 14:21:03 UTC