Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac)

[Daniel Kahn Gillmor <[e-mail]>]

On 04/11/2014 02:50 PM, Eric Rescorla wrote:

> Andrei Popov has refreshed his draft on deprecating RC4:
> 
> http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02

I would be happy to see RC4 go away, and if this helps push the 'net
across that boundary, I would be happy to see it.

I have two concerns with the current draft, though:


0) XP, WinServer2003, and even weaker ciphers
----------------------------------------------

Windows XP and Windows Server 2003 offer a very limited selection of
ciphersuites:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa380512%28v=vs.85%29.aspx

The only two ciphers that are close to plausible here RC4 and 3DES-CBC.
 The other ones are even weaker.

If we say that such a system shouldn't offer RC4, should they continue
offering the even weaker ciphers as well, like TLS_RSA_WITH_DES_CBC_SHA
or, uh, TLS_RSA_WITH_NULL_SHA ?  Do we have comparable text that
deprecates these other ciphers?

Windows XP was EOL'ed earlier this week, but everyone knows that it is
still in disturbingly widespread use.

Windows Server 2003 is supposed to be in extended support until the
middle of 2015.

Is there any prospect of an SChannel update for these systems that would
make these clients behave better on the modern network?


1) opportunistic TLS in fallback-to-clear contexts
---------------------------------------------------

as broken as RC4 is, it's better than cleartext.  There are contexts in
which TLS is used only when it can be negotiated, and otherwise the same
communication is retried in the clear.  One such example is SMTP mail
delivery.

It would be a net loss in security if this draft caused a mailserver to
fail to negotiate TLS, and then it came back and reconnected to deliver
the same message in the clear.

Some text that thoughtfully acknowledges this context and indicates what
servers and clients should do knowing that old peers exist would
probably be useful.



More generally, and i know i've banged on this drum before, i wish we
had a better idea about how to proactively deprecate weak crypto in
general.  It seems like we always do it in an ad-hoc fashion, and we
roll out new crypto without a thought about how we're going to deal with
its inevitable demise (except maybe by yanking it in some ad-hoc way in
the future).  I've got no good recommendations for how to do this, but i
would love to hear some.

	--dkg