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

[Viktor Dukhovni <[e-mail]>]

On Thu, Oct 23, 2014 at 12:04:29AM +0100, Stephen Farrell wrote:

> > So I think that it would be nice if there was some wiggle-room for
> > opportunistic TLS.  As weak as RC4 might be, it is stronger than
> > cleartext.  And the published bias attacks don't apply to MTA to
> > MTA SMTP.  There is no (pairwise) fixed sensitive plaintext at a
> > fixed offset in every MTA to MTA email transaction.
> > 
> > I have no objections to banning RC4 for "strict" TLS use-cases.
> 
> I think there is a significant difference between the security
> (in particular confidentiality) one gets with good and dodgy
> algorithms which is sufficient to argue that the OS design
> pattern is inappropriate to use with such dodgy algs.

I'd very much like to agree with you this year.  My concern is that
for now, there are still too many RC4-only sites, and disabling
RC4 will do more harm (in opportunistic TLS) than good in two ways:

    * Some communication will needlessly fall back to cleartext
      after STARTTLS fails, which might have succeeded with RC4.

    * Some communication will not fall back, and force users to
      statically downgrade transmission to cleartext by policy.
      Said policy will rarely get reviewed, and the RC4-only peers
      will be "pinned" at cleartext even after they upgrade.

Thus, while I am 100% for deprecation of RC4, the first step before
banning is I think a less radical phase-out.  With a bit of luck
sensible SMTP administrators will ignore the draft MUST NOT USE
language, and will instead arrange for RC4 to be a last-resort.
A few years from now, RC4 use will truly be negligible, and we can
start removing support.

If excluding opportunistic security is too painful, and it is better
for the draft to have an undiluted message than a nuanced one based
on more pragmatic considerations, fine, so be it, make it pure.
We'll muddle along violating it as necessary.

-- 
	Viktor.

P.S.  More eloborate TL;DR observations:

While I've largely eliminated inbound RC4 for my domain by configuring
the SMTP server to override client cipher suite preference with
more sensible settings on the server, I'm still sending out some
RC4 traffic, because Gmail overrides my client's cipherlist order
and elects ECDHE-RSA-RC4-SHA first.

If Google has not yet got the memo, it is perhaps premature to
expect the rest of the world to be ready.

If the draft goes ahead as-is, I'm of course prepared to offer
people advice on when/how to ignore its requirements, if needed to
resolve operational issues, but would prefer to not have to do
that.

I'd prefer to see a ban on RC4 for opportunistic uses a few years
after it is successfully eliminated for "strict TLS" and largely
phased out in opportunistic use with preference for RC4 over AES
disabled at most sites (more hardware AES support, fewer ancient
systems, ...).

At the end of the day, sure banning RC4 outright would not be
tragic.  People will largely continue to do what they're doing
today, and will generally only implement changes as part of software
upgrade cycles.

This means, for example, that if RC4 disappears from OpenSSL's
"DEFAULT" cipher list on the "master" (future 1.1.0) branch, and
OpenSSL 1.1.0 is released some time in 2015, operating system
releases might make this available to users in 2016, and users will
begin to adopt this in noticeable numbers by 2018.

So RC4 is likely with us through 2020, no matter what the RFC says.

Thus, for what it's worth, I am trying to prevent ~5 years of undue
pressure on thinking administrators from unthinking auditors.  By
2020, opportunistic TLS should I expect be ready to begin running
RC4-free.