Re: Re[6]: HTTP2 Expression of Interest

While use of port 443 and TLS may be a practical requirement for use
of SPDY under certain network constraints, a protocol requirement is a
very different matter.

It should be obvious that a protocol be capable of deployment under
common network contraints but that does not mean that every
implementation of the protocol MUST implement or use the work-around.


Nobody is even being very clear about the precise nature of the
requirement 'must implement TLS' and 'must use TLS' are very different
criteria. There is only one precedent for requiring implementation of
a security protocol in a non security protocol that I am aware of and
that is IPv6 which is hardly an inspiring precedent. I cannot think of
any case where a non security protocol has mandated use of encryption.

TCP is a very small protocol stack and HTTP is not much bigger.

TLS is a huge protocol stack and should not be implemented by people
who don't know what they are doing. We actively discourage
proliferation of crypto stacks in the security area these days.

PKIX is a big, complicated spec that has technical, legal and policy facets.

TLS requires PKIX, you can't have one without the other. So mandating
TLS in HTTP/2.0 is really mandating TLS+PKIX. If people don't want to
rely on CAs for their trust anchors they will also need DNS, DNSSEC
and DANE.





On Tue, Jul 17, 2012 at 11:56 PM, Mike Belshe <mike@belshe.com> wrote:
>
>
> On Tue, Jul 17, 2012 at 8:50 PM, Adrien W. de Croy <adrien@qbik.com> wrote:
>>
>>
>> ------ Original Message ------
>> From: "Mike Belshe" mike@belshe.com
>>
>>
>>
>> On Tue, Jul 17, 2012 at 8:34 PM, Adrien W. de Croy <adrien@qbik.com>
>> wrote:
>>>
>>>
>>> we can already transfer many objects over a single connection with
>>> HTTP/1.1
>>>
>>> SPDY without SSL would be more speedy than with it.
>>>
>>> There may be only a couple R-Ts to get an SSL handshake, but sprinkle on
>>> a CRL / OCSP check and you're left eating dust.
>>>
>>> So, let's just get this straight for the record.  SSL will not improve
>>> latency.  It will make it worse, and for many people (on
>>> already-high-latency links) a LOT worse.
>>
>>
>> Of course, no-SSL is lower latency than SSL.  It's not 3 RTs all the time,
>> but yes, OSCP can add a lot, and SSL implementations vary.  But SPDY gains a
>> lot of this back with fewer connections, multiplexing, and compression.
>> Don't forget to implement SSL False Start in your client.  Obviously an
>> un-optimized SSL stack will have a harder time than an optimized one.
>>
>> But its not true that every bit of latency is more important than
>> security.
>>
>> I'm just not convinced this would be a security win in the end.
>>
>> How many CAs are there?  We may as well right now deprecate OCSP / CRL
>> checks, because you have 200 million sites using a cert from one vendor, you
>> take out their OCSP server(s), and you've taken down 200 million sites.
>>
>> Way to go amplifying DOS effectiveness.
>> Becoming a CA is non-trivial.  If we suddenly need a million more of them
>> to cope with cert load, how do you anticipate that will improve security?  I
>> think it will make for a disaster.
>>
>
>
> The TLS concerns are legitimate.  We need to fix TLS to be even better, not
> make HTTP/2 weaker.
>
>>
>>
>> Note that Google has reported overall latency of SPDY + SSL is faster than
>> HTTP without SSL or SPDY.
>>
>> you saying SPDY + SSL faster than SPDY (presumably without SSL)?  Doesn't
>> seem possible.
>
>
> Oh - SPDY over port 80 is non deployable for the same reasons pipelining
> isn't deployable.  So that will never happen :-)
>
> But you're correct, I wouldn't expect SPDY + SSL to be faster than SPDY.
>
>>
>>
>> I have no problem accepting SPDY + SSL would be faster than HTTP.  But
>> we're talking about adding a bunch of things to HTTP that would provide the
>> same benefits that SPDY currently enjoys.
>
>
> Yeah, that's not going to fly....
>
> The problem is that the intermediaries just get stuck (they expect that port
> 80 is exclusively HTTP/1.1).  When you send them additional data, they
> sometimes hang, and this prevents deployment of new protocols.  Websockets
> has the same problem.  This is part of why no major sites are turning on
> websockets on port 80....
>
> But, regardless, SPDY gives us the window of opportunity through reduced
> latency to add security into the protocol without making latency worse.
>
> Mike
>
>>
>>
>>
>>
>>
>>
>>
>> Mike
>>
>>>
>>>
>>>
>>> ------ Original Message ------
>>> From: "Rajeev Bector" <rbector@yahoo-inc.com>
>>> To: "Adrien W. de Croy" <adrien@qbik.com>;"Martin Thomson"
>>> <martin.thomson@gmail.com>;"Martin J. Dürst" <duerst@it.aoyama.ac.jp>
>>> Cc: "Doug Beaver" <doug@fb.com>;"Willy Tarreau"
>>> <w@1wt.eu>;"ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
>>> Sent: 18/07/2012 3:26:56 p.m.
>>> Subject: Re: Re[2]: HTTP2 Expression of Interest
>>>
>>> Arguably, the cost of 3 Rts is amortized over many many objects that gets
>>> transferred over the session. That said, I am trying to imagine how to do
>>> crypto on my Arduino :-).
>>>
>>>
>>> From: "Adrien W. de Croy" <adrien@qbik.com>
>>> Reply-To: "Adrien W. de Croy" <adrien@qbik.com>
>>> Date: Tue, 17 Jul 2012 20:20:09 -0700
>>> To: Martin Thomson <martin.thomson@gmail.com>, "Martin J. Dürst"
>>> <duerst@it.aoyama.ac.jp>
>>> Cc: Doug Beaver <doug@fb.com>, Willy Tarreau <w@1wt.eu>,
>>> "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
>>> Subject: Re[2]: HTTP2 Expression of Interest
>>>
>>>
>>> ------ Original Message ------
>>> From: "Martin Thomson" <martin.thomson@gmail.com>
>>>
>>> On 17 July 2012 19:35, "Martin J. Dürst" <duerst@it.aoyama.ac.jp> wrote:
>>>
>>>
>>> So why are we okay with 10-20% more processing costs for everybody, but
>>> not
>>> with 10-20% more bandwidth? What's different between processing costs and
>>> bandwidth?
>>>
>>>
>>>
>>> Personally, I thought that the first optimization was for latency,
>>>
>>> How do you optimise latency by adding 3 RTs in a SSL setup?
>>>
>>>
>>>
>>> with bandwidth as secondary and (obviously) consequential.  Trade-offs
>>> may have to be made.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>



-- 
Website: http://hallambaker.com/

Received on Wednesday, 18 July 2012 04:26:35 UTC