W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: HTTP2 Expression of Interest

From: Mike Belshe <mike@belshe.com>
Date: Tue, 17 Jul 2012 21:43:02 -0700
Message-ID: <CABaLYCt8anXVArsX2mU2F79sTzHNtQSRLERDLtr2qAQC2TnjZQ@mail.gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: 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 Tue, Jul 17, 2012 at 9:33 PM, Phillip Hallam-Baker <hallam@gmail.com>wrote:

> No, RC4 is almost NEVER used on its own as you seem to imagine.
>
>
If you've ever looked at OpenSSL's config, you probably know they just call
it "RC4+MEDIUM" or something like that.  I was merely using the shorthand.



> What is used is actually RC4 + SHA1. And the real security value
> actually comes from the integrity check, not the stream cipher.
>

Yes, this is what Google uses.



>
> For HTTP/2.0 you would be much better off using AES-GCM which does
> encryption and integrity in one operation.
>

I'm not sure why this is better than RC4, when the author of this thread
was suggesting we should use no encryption at all.

Mike



>
>
> On Wed, Jul 18, 2012 at 12:16 AM, Mike Belshe <mike@belshe.com> wrote:
> >
> >
> > On Tue, Jul 17, 2012 at 8:59 PM, Phillip Hallam-Baker <hallam@gmail.com>
> > wrote:
> >>
> >> RC4 is cheap but SHA2 is not.
> >>
> >> Encryption without authentication is worthless. The principal security
> >> objective in TLS is to provide integrity, not confidentiality. If you
> >> lose integrity you are going to lose confidentiality even with 128 bit
> >> encryption.
> >>
> >>
> >> RC4 is a stream cipher. It is fast but thats about all that can be
> >> said in its favor. If I care about confidentiality I am not going to
> >> want a stream cipher.
> >
> >
> > I believe RC4 is excellent for almost all cases.  It is certainly used on
> > millions of sites today just fine.
> >
> > If the alternative is no security (e.g. arguing for no TLS), we can
> probably
> > agree that RC4 is more secure than that! :-)  Obviously, if you want even
> > stronger security, you can opt in to using other crypto algorithms -
> those
> > are configurable through TLS today.  No problem. Requiring TLS with
> HTTP/2.0
> > would not need to require an expensive symmetric crypto algorithm.
> >
> > Mike
> >
> >
> >
> >
> >>
> >>
> >>
> >> On Tue, Jul 17, 2012 at 11:44 PM, Mike Belshe <mike@belshe.com> wrote:
> >> >
> >> >
> >> > On Tue, Jul 17, 2012 at 7:35 PM, "Martin J. Dürst"
> >> > <duerst@it.aoyama.ac.jp>
> >> > wrote:
> >> >>
> >> >> Hello Doug, everybody,
> >> >>
> >> >>
> >> >> On 2012/07/18 7:11, Doug Beaver wrote:
> >> >>
> >> >>>    * Symmetric crypto costs are not much higher; I think Akamai
> quoted
> >> >>> 10-20%
> >> >>>      in their response. I think the costs aren't a big deal for
> major
> >> >>> sites;
> >> >>
> >> >>
> >> >> Just a quick question: I think if we could shave off 10-20% of the
> >> >> bandwidth with some new technique, we'd all go for it.
> >> >
> >> >
> >> > Symmetric crypto (RC4) is super super cheap - a couple of XORs -
> >> > definitely
> >> > not 10-20% of CPU.  I'd like to see that measured again before taking
> >> > action
> >> > upon it.  Obviously, if you use expensive crypto (presumably because
> you
> >> > want it), some algorithms take more CPU
> >> >
> >> > mike
> >> >
> >> >>
> >> >>
> >> >> 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?
> >> >>
> >> >> Regards,   Martin.
> >> >>
> >> >
> >>
> >>
> >>
> >> --
> >> Website: http://hallambaker.com/
> >
> >
>
>
>
> --
> Website: http://hallambaker.com/
>
Received on Wednesday, 18 July 2012 04:43:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 18 July 2012 04:43:37 GMT