Re: TAG work on SPDY

On 9/25/2011 11:33 AM, Jonathan Rees wrote:
> Caching and security do seem to be at odds. A similar situation is
> CSRF defense using nonces, which breaks cachability of HTML forms.
>
> There are probably architectural solutions to these conflicts. I don't
> know what they are, although I could probably make something up.

My concern with this is that SPDY is introduced primarily for performance, 
but as far as I can tell uses SSL unconditionally. Thus, even information 
that would otherwise not require protection might be less easily cached. 
So, there's a risk, I think, that the on-the-wire performance of a 
particular retrieval would in certain cases be traded for increased load on 
an origin server, and perhaps increased aggregate network traffic, as more 
copies are sourced directly from the origin.

I should emphasize that I'm just speculating that there might be an impact 
on cacheing, and I'd be happy to hear from those who know more about SPDY 
that there is no problem.

> Architecturally the important thing is the interface or contract, not
> choice of implementation (protocol). To answer this question we'd need
> to know what requirements HTTP meets, and then see if SPDY meets them
> too. (I think I'm repeating Roy's "http: is not HTTP" slogan here.
> According to the specs at least, http-scheme URIs aren't tied to the
> HTTP protocol, and the HTTP protocol is not limited to http-scheme
> URIs.)

Long ago when the TAG was discussing my (as yet unsucessful) attempts to 
formalize the relationship between schemes and protocols, it was pointed 
out that the naming contract for http-scheme resources is somewhat 
different than for https. That is, when you retrieve an https-named 
resource part of the contract is that certificates will be checked as part 
of the name resolution. That's not in general true of otherwise similar 
http-named resources.

So, if the switch were being done in the other direction we would be highly 
suspicious: resolving an https URI without checking certs is inapproriate. 
SPDY goes the other way, with at least some consideration to using SSL (and 
thus, I presume, certs?) for http URIs. This seems like a safer switch, but 
it really is a change of contract.  Today, access to my http-named 
resources cannot fail due to certificate problems, and it seems there's 
consideration of changing that.

I'm not offering an early opinion as to whether that's bad, merely that it 
needs careful thought. Also: my impression is that SPDY is mostly used with 
https-named resources anyway, but I did see something somewhere about 
automatically switching to HTTPS even for http URIs.

Noah

Received on Sunday, 25 September 2011 22:13:13 UTC