Re: Re[6]: HTTP2 Expression of Interest

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