- From: Phillip Hallam-Baker <hallam@gmail.com>
- Date: Wed, 18 Jul 2012 08:16:18 -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>
On Wed, Jul 18, 2012 at 1:13 AM, Mike Belshe <mike@belshe.com> wrote: > > > On Tue, Jul 17, 2012 at 9:58 PM, Phillip Hallam-Baker <hallam@gmail.com> > wrote: >> >> 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. > > > There was a time, long ago, when people were flabbergasted by the idea that > you'd use HTTP to control your lightbulb too. "I have to put an HTTP stack > on a lightbulb? I could just use UDP!" I suggest we design for the future, > not the past. Mandating bloat is not designing for the future. I am talking about the present. I HAVE a light bulb (actually a board with LEDs mounted) that has a Web server embedded. One of the design requirements of a lightbulb is instant-on. >> 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. > > > It's all negotiated in the handshake. You'll know who is TLS and who is > not. Not without knowledge of the security policy. Without that you are subject to a downgrade attack. > It does provide lots of better security. The internet cafe is the best > example. I know you're aware of Firesheep. We should make it impossible to > use firesheep in 2020. Right? I would much prefer to get rid of password based authentication which is the driving use case for most use of SSL.
Received on Wednesday, 18 July 2012 12:16:53 UTC