Re: HTTP2 Expression of Interest

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