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

Hi, dkg

It’s not clear to me whether the draft is targeted at developers or deployers. If the former, it comes too late to apply to XP and Win2003. If the latter, you can still configure your server to only offer 3DES. While not the best cipher out there, if someone is stuck and cannot upgrade to Win2008, it is (as you say) the only plausible thing.

For people stuck on XP, there’s still Chrome, Firefox, and Opera. If they insist on using software that is all 10 years old, a new RFC can’t apply to them. If you use IE you can’t turn off ciphersuites. Or maybe there’s some secret registry hack, but if you’re technical enough to hack the registry, you’re technical enough to install a more modern browser or OS.

Those other weak ciphers should be gone as well. There is no good reason today to have “export” ciphersuites. NULL can stay, but nobody in their right minds uses that in a server that is supposed to offer confidentiality. Those ciphersuites are like AH in IPsec, a rarity that is useful in a few edge cases.

As for opportunistic encryption, while it’s true that RC4 is better than nothing, anything that can do RC4 can do better things. Even if those "better things" are 3DES-CBC in TLS 1.0.

Yoav

On Apr 11, 2014, at 10:31 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:

> 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
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls