W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: Ascii-based SPDY "compression" idea

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Mon, 02 Apr 2012 15:04:35 +0000
To: ifette@google.com
cc: (wrong string) ™ˆ™˜Œ) <willchan@chromium.org>, ietf-http-wg@w3.org, Peter Lepeska <bizzbyster@gmail.com>
Message-ID: <90627.1333379075@critter.freebsd.dk>
In message <CAF4kx8dt=2m6viL_6Hf8OAj1v7RzYBVS38wSt6WV28DY6KZWpQ@mail.gmail.com>
, =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= writes:

>What i was getting at is that if your "http router" is also doing SSL
>termination, 

The architecture right now does not allow routing without TLS termination,
and that is a major bottleneck for high-traffic sites.

What I tried to sketch out, was a way to allow routing without terminating
the TLS session, in order to reduce the processing load on the router.

This would allow deployment of HTTP routers in front of TLS certificates
you don't have access to, something data centers and web-hosting
companies might appreciate.

>Re: which items need to be encrypted, on an HTTPS page, everything on the
>page needs to be encrypted, so there's really no signaling involved...

I agree that with respect to man-machine interface, that is probably
the correct starting point.

But I can imagine a lot of situation where a more granual approach
would work better:

	Get http://video-on-demand.example.com/
	redirects to TLS protected login.example.com
	user logs in on TLS protected page
	user picks video on TLS protected page, get DRM key back.
	DRM protected video is streamed without TLS protection.

The actual video might even come from a different server than
the TLS session, if a HTTP router was deployed, but the client
still sees just one TCP connection.

But as I said:  There is a lot of clarity to be had with an
all-or-nothing approach to TLS.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Monday, 2 April 2012 15:05:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:59 GMT