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

[Hubert Kario <[e-mail]>]

On Thursday 23 October 2014 06:00:03 Viktor Dukhovni wrote:
> 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.

Looking at web servers, less than 1% support only RC4 ciphers, the
rest of the 21% that end up negotiating RC4 will gladly negotiate
different ciphers (mostly AES based ones) if the client doesn't offer
RC4.

> 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.

How long since we got to know that RC4 is really bad? And this draft
is still not an RFC. Let's say that we will change it to say that the RC4 MUST 
be placed last (both client and server side) and release it today. How long 
will it take to release a new RFC that says that it MUST NOT be used?
How long will it take for majority (let's say 75%) of server admins that are 
not compliant with it to actually implement this policy? How many of them will 
unknowingly ignore it?

Just those issues in itself will cause the RC4 depreciation to have a de facto 
transition period. Just look for statistics of the OpenSSL CCS and Hartbleed 
fixes deployments, and those were security vulnerabilities, not best practice 
recommendations.

Second issue is that opportunistic encryption is completely vulnerable to 
active MITM attack, isn't it? This in itself makes it non-RFC compliant, at 
the very least, from the TLS point of view.

-- 
Regards,
Hubert Kario