- From: Mike Belshe <mike@belshe.com>
- Date: Tue, 17 Jul 2012 21:43:02 -0700
- 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>
- Message-ID: <CABaLYCt8anXVArsX2mU2F79sTzHNtQSRLERDLtr2qAQC2TnjZQ@mail.gmail.com>
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 UTC