- From: Phillip Hallam-Baker <hallam@gmail.com>
- Date: Wed, 18 Jul 2012 00:58:16 -0400
- To: Mike Belshe <mike@belshe.com>
- Cc: "Adrien W. de Croy" <adrien@qbik.com>, Rajeev Bector <rbector@yahoo-inc.com>, Martin Thomson <martin.thomson@gmail.com>, Martin J. Dürst <duerst@it.aoyama.ac.jp>, Doug Beaver <doug@fb.com>, Willy Tarreau <w@1wt.eu>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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