- From: Phillip Hallam-Baker <hallam@gmail.com>
- Date: Wed, 18 Jul 2012 01:03:00 -0400
- To: Mike Belshe <mike@belshe.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>
AES is a block cipher and they are a lot more resistant to protocol design issues. RC4 was a barely acceptable approach in 1994 when it was first adopted in SSL 1.0. It is really not an acceptable cipher in 2012. On Wed, Jul 18, 2012 at 12:43 AM, Mike Belshe <mike@belshe.com> wrote: > > > 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/ > > -- Website: http://hallambaker.com/
Received on Wednesday, 18 July 2012 05:03:28 UTC