Re: Re[6]: HTTP2 Expression of Interest

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

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?

Mike


>
>
>
> 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/
>