Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

[Ryan Carboni <[e-mail]>]

>
> The main concern that I have with this approach is that attacks against
> RC4 will only get better and while the attacks may be currently impractical
> against HTTP cookies perhaps there are other usages where the problem may
> be greater.
>
> Pragmatically, implementers will do what is necessary to interoperate, so
> I think something along the lines of what Chris recommends below may be the
> best way forward.    I'm a bit reluctant to bring opportunistic security
> into the discussion at this point, but I think the rest is OK.
>
> Do folks think this is an acceptable way forward?
>
> Thanks,
>
> Joe


This is a common misconception. Cryptography isn't a linear effort. As
knowledge of cryptography improves through research, that knowledge is
applied through the design of future ciphers. This is why MD5 was easily
broken, but only after knowledge had improved. After theoretical attacks on
SHA-1 emerged, people used the trendline of how quickly md5 failed to
determine that SHA-256 will fall in about 5 to 15 years. Thus there was a
SHA-3 hash competition, but it turned out that the trendline failed, the
knowledge on which SHA-256 was built was superior to md5.

This is why SHA-256 will never have a malicious collision, and why RC4 will
never be broken. RC4 is a primitive design and Rivest got lucky in
designing a good cipher when knowledge of cryptography was so poor.
Preimaging the internal state of RC4 based on it's output will be
difficult, partly why the best attack from that direction is around 2^700.

RC4 shouldn't be used in new protocols much like md5, ChaCha8 128-bit
should probably replace RC4, but there aren't many fast ciphers currently
implemented in clients right now. And it will take years for
implementations to spread. It isn't practical to remove RC4 based on using
trendlines of past events when they don't apply in the same situation.

The number of possible permutations that could lead to a given RC4 output
is staggering, once again, the best attack on RC4's output is 2^700.
Attacks do not improve linearly, that is RC4 does not become 2^-10 less
secure each year.


On a minor note, after disabling RC4 and non-forward secrecy cipher suites,
I find my firefox browser negotiates Triple DES with servers with some old
set of cipher suites. I really do wish client side prioritization was
possible.

If you guys really want to disable RC4, why not disable Triple DES? It's
horribly insecure and is certainly "closer" to a break than RC4. It's 2^90
(despite a 168 bit key) at best, particularly with some precomputation
involved.