Re: [TLS] RC4 depreciation path (Re: Deprecating more (DSA?))

On Sat, Apr 19, 2014 at 12:32 PM, Fabrice <fabrice.gautier@gmail.com> wrote:
>> On Apr 19, 2014, at 6:10, Kurt Roeckx <kurt@roeckx.be> wrote:
>>
>>> On Fri, Apr 18, 2014 at 11:03:44PM -0700, Watson Ladd wrote:
>>>> On Thu, Apr 17, 2014 at 9:15 AM, Brian Sniffen <bsniffen@akamai.com> wrote:
>>>> Alyssa Rowan <akr@akr.io> writes:
>>>>
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA512
>>>>>
>>>>> It looks like RC4 is rapidly heading for the chopping block, with
>>>>> basically unanimous consensus. Good.
>>>>
>>>> Agreed, mod Martin's proposal that I understand to ask for a reasonable
>>>> path by which we strongly deprecate RC4 on clients, then after a client
>>>> generation ban RC4 on clients and deprecate for servers.
>>>
>>> I don't think this is the correct path. I think what we should do is
>>> have clients and servers both prefer other options (in all TLS
>>> versions), then once that change is made, ban it entirely. Deprecation
>>> on one side won't affect the other side if there isn't an alternative
>>> mandated. (Right now RC4 only servers are keeping RC4 alive).
>>>
>>> This first step has already happened in the web context on modern
>>> browsers. What we need is to make the server side step happen, and
>>> then think about removal in the second step.
>>>
>>> Sadly, our ability to force upgrades is very limited.
>>
>> And I think publishing an RFC isn't actually really going to help
>> much.
>
> Not much, but a little bit. I think there are still a lot of people (including myself) that are not convinced that the severity of the attacks against RC4 justify removing it yet. I'm not an expert enough to be able to tell if the various published papers about RC4 are mostly theoretical issues, or practical ones.
>
> If the IETF comes out with an RFC officially deprecating it, that's one more thing telling me this is serious enough that it should really be looked at.

Have you seen the graphs of recovery probability against number of
connections? It's pretty bad.

The big idea is to use Fluherer-McGrew biases+Hidden Markov model
algorithms. That's assuming no more cryptanalysis results. I don't
think that's a good assumption.

>
>> Yes, people could use it tell others that it's deprecated,
>> but I think there are already more than enough places that say so
>> that having this RFC isn't really going to make a difference
>
>> I do agree that we need to try to get both sides to stop using it,
>> and I wish we could just tell people to stop using it and that
>> they would do so.  But I don't see either the server or the client
>> side wanting to break things.  It would clearly help if they could
>> say at which point they wouldn't mind breaking things
>
>> So I think that for now the best we can do is:
>> - Servers should either stop accepting RC4 or make sure that
>>  if the clients supports something better (TLS >= 1.1?) it should
>>  not pick RC4.
>
> I would think there would be very few if any clients out there that only support RC4. But I would expect some servers out there do no support RC4 already.
> Although I have no actual data to support my gut feeling here, and would be glad to be proven wrong.

It's a server-side workaround for BEAST. Not all old IE versions have
1/n-1 record splitting. I'm part of the problem here: my dad refuses
to get a new computer, so IE6 on XP it is. However, old IE isn't
vulnerable without plugins.

Vanguard.com is a website using RC4 on modern browsers. The reason for
this is partly BEAST and partly a misconfiguration in which they
support TLS 1.2, but still want RC4. It's this sort of issue which we
can solve easily. Removing RC4 from browsers wouldn't break them.

>
>>  It's my understanding that the client preferences of ciphers
>>  should be used but that servers can override that, and that
>>  there might be good reasons to do so. For instance to get PFS
>>  when talking to Internet Explorer.  If they override it, they
>>  should make sure not to put RC4 first.  Basically, a mondern
>>  client should never get RC4.
>> - Clients should not announce support for RC4 in their initial
>>  connection attempt, and only fall back to support it when the
>>  server says that there are no common ciphers.  (I'm not sure
>>  if a MITM can fake that response or not.)
>>
>> At some point in time when the clients or servers think that they
>> don't need to support RC4 anymore they should disable it.
>>
>>
>> Kurt
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin