Re: TAG work on SPDY (was: More on SPDY & relationship to buffer bloat)

On Sat, Sep 24, 2011 at 11:49 AM, Noah Mendelsohn <nrm@arcanedomain.com> wrote:
>
> On 9/23/2011 6:05 PM, Jeni Tennison wrote:
>>
>> http://bitsup.blogspot.com/2011/09/spdy-what-i-like-about-you.html
>>
> Thanks! Given that SPDY is starting to get this sort of attention and
> early-adopter uptake, this seems like a time the TAG might start to get more
> serious about evaluating the architectural impact of widespread adoption of
> SPDY or similar techniques. Issues that occur to me include:
>
> * Impact on interoperability: the TAG has suggested [1] that the bar be set
> very high on replacement of the core protocols that are widely deployed. The
> cost/benefit for SPDY may be good, but we might want to take a close look at
> the pros and cons.
>
> * SPDY mandates use of SSL. There seem to be several impacts that might be
> of concern to the TAG:
>
>  1. Possible impact on cacheing

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.

>  2. Applicability to http-scheme names
>     and when it is/isn't appropriate
>     to use SPDY for such resources

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.)

>  3. Does this create a requirement to
>     have a cert if you host a Web site?

>From what you say it sounds like it does. If so then this is
definitely an annoyance and, under current browser behavior,
undemocratic.

I've always wondered - SSL bundles channel privacy with a particular
authentication system. This to me has always seemed idiotic since the
two concerns are independent - once you have a private channel you can
then use whatever authentication system you want, or none at all. (Of
course the channel isn't credibly private until you can trust the
other end not to broadcast the communication; but trust can be
established in public, if I understand how this stuff works.)  Does
anyone on this list know of a *technical* reason that SSL is designed
this way? Or is it an accident, possibly driven by market forces
(desire to sell authentication services)?

So, I can see why SPDY likes privacy, but not (technically) why it
would insist on a particular authentication mechanism.

On the other hand requiring certs for all servers could be a stimulus
to improving the infrastructure for self-signed certs and
decentralized webs of trust, and that would be a good thing.

>  4. Privacy groundrules might change
>     (perhaps for the better) if
>     typical Web traffic is encrypted

Security and privacy are pretty much unrelated - no solution to one is
of much help to the other - so I don't think so. Security has to do
with your relationships with those who can't be held to account;
privacy is about holding accountable those who ought to be.

> * If changes like this are to be introduced, is SPDY indeed the right
> technology to use?
>
> There may be other pros or cons. I've not listed above the obvious "pros",
> which are improved performance, probable reduced "buffer bloat", etc.
>
> I'm curious whether other TAG members agree that this is worth a look, and
> if so, whether any of you are interested in taking the lead in at least the
> first round of work? We can discuss on the call next week.
>
> Jeni: Thank you again for highlighting this.
>
> Noah
>
> P.S. Adding Jim Gettys to the cc: list. Jim, the threads on this start at
> [2,3]

Yes, I'd love to hear Jim's take on it.

Best
Jonathan

> [1] http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html#stablelayers
> [2] http://lists.w3.org/Archives/Public/www-tag/2011Sep/0027.html
> [3] http://lists.w3.org/Archives/Public/www-tag/2011Sep/0033.html
>

Received on Sunday, 25 September 2011 15:34:13 UTC