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

[Watson Ladd <[e-mail]>]

On Fri, Oct 3, 2014 at 6:30 AM, Viktor Dukhovni <[e-mail]> wrote:
> 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.

<snip>
What advice do you want to give them, and how will it end the use of
RC4? The advice given is to not offer RC4 cipher suites on the client
side, and not to pick them on the server side: are we only debating
the third point? Or are you saying that clients should feel free to
offer RC4, and servers should be configured to pick it last?

Sincerely,
Watson Ladd
>
> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> 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