Re: Re[6]: HTTP2 Expression of Interest

My lightbulbs have HTTP stacks and run web services. If I want to
modify the lighting, I send them a command to dim, brighten, change
the color balance or whatever.

They do not have an operating system or anything like it. That would
require a much bigger chip and a much higher current drain when not in
use.

The world of HTTP is a lot more than just Web browsers.


Mandating TLS in 2.0 will not provide an ounce of extra security
unless you have a way to know who is running 2.0. And if you can do
that you do not need the mandate.



On Wed, Jul 18, 2012 at 12:38 AM, Mike Belshe <mike@belshe.com> wrote:
>
>
> On Tue, Jul 17, 2012 at 9:26 PM, Phillip Hallam-Baker <hallam@gmail.com>
> wrote:
>>
>> 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.
>
>
> I thought everyone was talking about "must use TLS".
>
>
>
>>
>>
>> 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.
>
>
> I basically agree with this, yes.
>
> Except most can get this from their operating system.  It's provided for
> free in windows, macos, ios, and I believe android (but I have to check).
>
>
>>
>>
>> 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.
>>
>
>
> CA trust anchors are policy, not implementation.
>
> I would propose do what other protocol specs do, which is to leave policy to
> the implementations.
>
> Mike
>
>
>>
>>
>>
>>
>>
>> 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/
>
>



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

Received on Wednesday, 18 July 2012 04:58:44 UTC