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

[Viktor Dukhovni <[e-mail]>]

On Fri, Oct 03, 2014 at 12:02:02AM -0700, Watson Ladd wrote:

> > A more realistic document is I think likely to see greater adoption.
> 
> Let's be 100% clear here: RC4 is not required for interoperability, as
> TLS 1.0, 1.1, and 1.2 all specify other MTI suites for interop.

In theory, but in practice it is.

> Disabling RC4 is possible. It needs to be disabled, whether by no
> longer offering it or administrator action. The Lucky 13 and BEAST
> attacks require either client "features" and are mostly patched
> anyway.

A MUST NOT prefer RC4 is something one can realistically implement.
A MUST NOT offer is something that many will be forced to ignore.
An auditor can just as easily write findings about SHOULD NOT as
MUST NOT.

Documents that don't match operational reality are I think
counter-productive.  They eat away at the credibility of the
standards body publishing the document.

Before RC4 becomes MUST NOT, it needs to first become a low priority
algorithm that is used when nothing better is available.

With Exchange 2003 email servers that are still operating at some
domains the only working ciphersuites are RC4-MD5 and RC4-SHA.
Operators will ignore the IETF and leave RC4 enabled so that mail
can continue to be sent to these domains.

Note also that MTA to MTA mail transactions generally don't carry
fixed sensitive text at a fixed position in the first 256 bytes of
the client or server TLS stream.  This is only an issue with
submission when the client is using "AUTH PLAIN" or "AUTH LOGIN".

I am strongly in favour of educating operators about the weakness
of RC4, provided we give them operationally realistic advice.
I don't see how MUST NOT is such advice.

-- 
	Viktor.