Subject: [Uta] On prohibiting RC4

From: "Salz, Rich" <[email-masked]>
Date: Fri, 7 Mar 2014 05:01:51 -0500

As requested, posting this to the list.  My concern about the "prohibiting RC4" draft is that it is too broad.  For TLS 1.1 and beyond, we should definitely not use RC4 as there are better alternatives.  For TLS 1.0, a case can be made that RC4 is the best choice, or the least-worst.  For example, see http://blog.cloudflare.com/killing-rc4 (including the comments).

--
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Alyssa Rowan <[email-masked]>
Date: Fri, 07 Mar 2014 11:37:58 +0000

On 07/03/2014 10:01, Salz, Rich wrote:

> As requested, posting this to the list.  My concern about the 
> “prohibiting RC4” draft is that it is too broad.  For TLS 1.1 and 
> beyond, we should definitely not use RC4 as there are better 
> alternatives.  For TLS 1.0, a case can be made that RC4 is the best
> choice, or the least-worst.  For example, see 
> http://blog.cloudflare.com/killing-rc4 (including the comments).

I'm seeing the comments. Do you have any comments yourself? Which are
you referring to? Piotr Sikora's belief that RC4 is better than
AES-CBC without 1/n-1 record splitting?

With respect, I think he's simply wrong, because (and we've been over
this ground previously on this list, in December/January) passive
breaks are a much greater threat than active BEAST attacks.

I have heard from sources I trust that NSA can passively crack RC4 in
SSL/TLS in or about real-time: they are apparently doing so en-masse,
and (importantly!) to historically-captured traffic.

If so, they must have really liked people switching to it to avoid the
BEAST active attack - a mistake we should not make.

BEAST attacks are active, and perpass normally has no means to perform
them. That is not to say that those active attacks do not pose a risk,
but that they pose a lower risk to a known adversary normally in the
Eve position rather than Mallory, than that posed by a critically weak
cipher, such as we believe RC4 may be, or at very least, will soon be.

For SSLv3 legacy handshakes - if really, REALLY required - I'd say
choose [000a] TLS_RSA_3DES_EDE_CBC_SHA, and consider telling those
running IE6 on XP to upgrade (the days are numbered anyway). [I note
Akamai seem to have reached the same conclusion on live servers, so I
assume you're simply playing Devil's Advocate here?]

For both TLSv1.0 & v1.1, [003c] TLS_RSA_WITH_AES_128_CBC_SHA256 or
[002f] TLS_RSA_WITH_AES_128_CBC_SHA would be better alternatives, and
those would be the least-worst ciphersuites available there.

That is why I recommended RC4 is removed from ciphersuite offerings
completely, and removed entirely (along with other weak ciphers) from
all future versions of TLS. And it MUST NOT be offered or allowed,
otherwise peers following previous advice to avoid BEAST may choose
RC4 over stronger ciphers, which would be problematic.

In any case, I support the prohibiting-rc4 draft in its current form,
and would like to reach consensus on it as rapidly as possible.

If you have any specific points or counterpoints, I'm sure we'd all
love to hear them.

- -- 
/akr

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 7 Mar 2014 07:46:34 -0500

> With respect, I think he's simply wrong, because (and we've been over this ground previously on this list, in December/January) passive

It depends on what you're concerned about.  From a global view, I'm concerned about perpass. From a commercial view, I'm perhaps more worried about my customers getting through to me.

> I have heard from sources I trust that NSA can passively crack RC4 in SSL/TLS in or about real-time: they are apparently doing so
> en-masse, and (importantly!) to historically-captured traffic. ...  If so, they must have really liked people switching to it to avoid the BEAST
> active attack - a mistake we should not make.

You're not seriously expecting me to take this undocumented assertion without skepticism, are you?

> BEAST attacks are active, and perpass normally has no means to perform them.

> That is not to say that those active attacks do not pose a risk, but that they pose a lower risk

Not everyone feels this way.

> so I assume you're simply playing Devil's Advocate here?

No.

> If you have any specific points or counterpoints, I'm sure we'd all love to hear them.

I'll wait until the minutes are published which will hopefully contain ekr's view which (rightfully) carries more weight than mine.

	/r$

---

From: Alyssa Rowan <[email-masked]>
Date: Fri, 07 Mar 2014 14:20:14 +0000

On 07/03/2014 12:46, Salz, Rich wrote:

> It depends on what you're concerned about.  From a global view, I'm
> concerned about perpass.

As are we all, and the reason for this discussion.

> From a commercial view, I'm perhaps more worried about my customers
> getting through to me.

I understand that: try [000a] TLS_RSA_3DES_EDE_CBC_SHA as a failsafe
for legacy clients, iff [002f] TLS_RSA_WITH_AES_128_CBC_SHA is not
supported? 3DES is supported as far back as RC4 is, it's not choice
anymore but it's not precipitously weak, and we were discussing that
back in December and January. Problem solved, as far as I can see?

If any of your customers outright require RC4 specifically, well then
They're Doing It Wrong - and the draft under discussion is the
document that will notify them that they are going directly against
good advice.

>> [re: RC4 is broken in real time by the #NSA - stop using it.]

Of course not. Scepticism is entirely reasonable. I am relaying what
I've been told by sources that _I_ trust, not asking you to trust them
in turn.

But still, being sceptical and ignoring that, it is the best fit for
the huge 'cryptologic breakthrough' that is referenced in the Snowden
docs. Perhaps ask Jacob Applebaum or Bruce Schneier for more info
(although I think if they had any details, they would happily have
disclosed them, and I understand the Snowden docs do not contain
details like that).

For the record, I would love to see such a cryptanalytic breakthrough
documented in the public literature, and I encourage anyone who has
sufficient access to fully disclose it in both the interest of global
security and for the furtherance of science.

Discounting that entirely, even what we know publicly, from 2013,
strongly suggests deprecation of RC4 is already long overdue and we
need to move away from it right now. Surely you don't contest that.

> Not everyone feels this way.

I would be very interested to hear their reasons in detail, but with
respect, their conclusions are simply wrong.

As I have said, passive attacks are available to Eve and can be
applied retrospectively; active attacks are only available to Mallory
and cannot. Passive attacks therefore present a greater threat than
active attacks.

>> so I assume you're simply playing Devil's Advocate here?

Oh? Forgive my assumption: the arguments in the third-person confused me.

> I'll wait until the minutes are published which will hopefully 
> contain ekr's view which (rightfully) carries more weight than 
> mine.

Very well. I'm sure I shall look forward to reading them.

- -- 
/akr

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 7 Mar 2014 09:25:34 -0500

> Of course not. Scepticism is entirely reasonable. I am relaying what I've been told by sources that _I_ trust, not asking you to trust them in turn.

You are asking me to trust you.

How do I know that you're not trying to trick me into using a cipher that has been broken?

	/r$

---

From: Alyssa Rowan <[email-masked]>
Date: Fri, 07 Mar 2014 14:33:58 +0000

> cipher that has been broken?

A fair point: I understand any scepticism, and I look forward to the
minutes and further discussion.

Of course, if you're trying to pick a strong cipher, you're in
draft-sheffer-tls-bcp territory: we're discussing last resort choices
here.

- -- 
/akr

---

From: Andrei Popov <[email-masked]>
Date: Fri, 7 Mar 2014 19:22:46 +0000

> It depends on what you're concerned about.  From a global view, I'm concerned about perpass. From a commercial view, I'm perhaps more worried about my customers getting through to me.

Are you dealing with a significant number of RC4-only TLS clients? When we tried to disable RC4 altogether here at MS, the issues we ran into were mostly with the TLS servers that would not speak anything but RC4 (not just web servers, but other applications such as e-mail). We were nevertheless able to have IE not offer RC4 on the initial connection attempt. 

If adopted, the RC4 deprecation draft would hopefully send a strong message to the industry and help us phase out RC4 sooner.

Cheers,

Andrei

-----Original Message-----
From: Uta [mailto:[email-masked]] On Behalf Of Salz, Rich
Sent: Friday, March 7, 2014 4:47 AM
To: Alyssa Rowan; [email-masked]
Subject: Re: [Uta] On prohibiting RC4

> this ground previously on this list, in December/January) passive breaks are a much greater threat than active BEAST attacks.

> and (importantly!) to historically-captured traffic. ...  If so, they must have really liked people switching to it to avoid the BEAST active attack - a mistake we should not make.

No.

	/r$

_______________________________________________
Uta mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/uta

---

From: Franck Martin <[email-masked]>
Date: Fri, 7 Mar 2014 13:56:24 -0600 (CST)

----- Original Message -----
> From: "Andrei Popov" <[email-masked]>
> To: "Rich Salz" <[email-masked]>, "Alyssa Rowan" <[email-masked]>, [email-masked]
> Sent: Friday, March 7, 2014 7:22:46 PM
> > concerned about perpass. From a commercial view, I'm perhaps more worried
> > about my customers getting through to me.
> 
> Are you dealing with a significant number of RC4-only TLS clients? When we
> tried to disable RC4 altogether here at MS, the issues we ran into were
> mostly with the TLS servers that would not speak anything but RC4 (not just
> web servers, but other applications such as e-mail). We were nevertheless
> able to have IE not offer RC4 on the initial connection attempt.
> 
> If adopted, the RC4 deprecation draft would hopefully send a strong message
> to the industry and help us phase out RC4 sooner.
> 
I have not dived into this selection process yet, but I see RC4 a lot in SMTP.

I think the problem is in ciphersuite selection, it is the client that propose a list of ciphers and the server that picks the one it likes. The whole selection process seems not standardized or with little control settings.

Is someone making (or has already done) a standard to select ciphersuites, and can they rank the ciphersuites across 2 dimensions: speed, strength?

It seems openssl allows you to select the cipher list in an ordered fashion:
https://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT
"Include only 3DES ciphers and then place RSA ciphers last: openssl ciphers -v '3DES:+RSA'"

What the string should be? How hard is it to manage this string and keep it up to date? Can this work group (or the TLS one) provide some regular advice?

"the cipher string @STRENGTH can be used at any point to sort the current cipher list in order of encryption algorithm key length."
Seems to me we need the sort to be in the opposite direction from strong to weak...

That's openssl, what about gnuTLS?

There is a great deal of configuration in postfix on this subject, but basically it relies on openssl point of view:
http://www.postfix.org/TLS_README.html#server_cipher

This should not be rocket science for most postmasters.

Then, we can place RC4 last for opportunistic TLS and eventually deprecate it.

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 08 Mar 2014 07:46:47 +0200

Hi Andrei,

I'm not sure I understand your response. The way I parse it, in 
*today's* Internet, assuming we never want to resort to cleartext, what 
would work is:

- Client initiates handshake #1 without RC4.
- Server (sometimes, if it's old) fails the handshake. This failure is 
unauthenticated, which means it can be forced by an attacker.
- client fallbacks to handshake #2 with RC4 (which by the way, is 
disallowed by the draft).
- Server's happy.

IMHO this would only complicate fallback logic (which in an ideal world 
we should have gotten rid of) without improving security.

If we're saying MUST NOT we must be able to stand behind it. If we 
can't, let's try to craft more nuanced language.

The current draft would fail the connection and thereby fallback to 
cleartext if the client only offers RC4. Even if such clients are rare, 
this is still a grave mistake IMO.

Thanks,
	Yaron

---

From: Martin Thomson <[email-masked]>
Date: Sat, 8 Mar 2014 07:12:38 +0000

On 8 March 2014 05:46, Yaron Sheffer <[email-masked]> wrote:
> If we're saying MUST NOT we must be able to stand behind it. If we can't,
> let's try to craft more nuanced language.

I think that the difference is between "prohibited" and "deprecated".

I think that at this stage, the intent is to say "Implementations MUST
NOT use RC4 unless there are no better options."

Definition of "better", TBD.  Probably, at this point, everything else
that is not also deprecated.

I'd hope that this doesn't mean that implementations have to implement
the fallback Andrei has.  That mostly seems to be a way for the client
to influence the choice, though I note that penalizing servers who
deploy RC4 is an interesting idea.

It does mean that a server cannot accept RC4 when better options are
available.  It also means that perhaps clients should fail the
handshake in cases where the server negotiates RC4, unless we decide
that 3DES is strictly worse.  My understanding was that 3DES was only
bad from a performance perspective, but I'm not going to try to
persuade Rick one way or the other there :)

I hope that it would be uncontroversial if we said that clients should
fail the handshake in the case that TLS 1.2 is negotiated.

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 08 Mar 2014 10:23:35 +0200

> NOT use RC4 unless there are no better options."
Yes, this is what I mean by "nuanced". So let's spell it out in the 
document.
> fail the handshake in the case that TLS 1.2 is negotiated.
An RC4-only TLS 1.2 server is obviously misconfigured. But I don't think 
falling back to cleartext is the appropriate penalty for 
misconfiguration. IMHO even single-DES is better than cleartext (but 
don't quote me on that :-).

And to answer the obvious question: this is a "hard fail" and will make 
people fix the configuration - what may be easily visible to browser 
users is not necessarily so to other TLS-using applications.

---

From: Martin Thomson <[email-masked]>
Date: Sat, 8 Mar 2014 09:13:11 +0000

On 8 March 2014 08:23, Yaron Sheffer <[email-masked]> wrote:
> But I don't think falling back to cleartext is the appropriate penalty for
> misconfiguration. IMHO even single-DES is better than cleartext (but don't
> quote me on that :-).

That's a hard one.  A failure provides some incentive to fix the
problem.  On the other hand, it has other less positive effects.

---

From: Andrei Popov <[email-masked]>
Date: Mon, 10 Mar 2014 17:46:18 +0000

Hi Yaron,

You are right in saying that browser re-connects are insecure, and that an active attacker can cause the browser to re-connect with RC4 enabled. While in our experiments at the time, this re-connect behavior drastically reduced the use of RC4 with IE, the ultimate solution is to never negotiate RC4 with TLS, which is the purpose of the Internet-Draft we're discussing.

The entire world certainly won't eliminate RC4 overnight, but I believe that it makes sense to do regular housekeeping and remove known broken crypto from current RFCs.

Cheers,

Andrei

-----Original Message-----
From: Yaron Sheffer [mailto:[email-masked]] 
Sent: Friday, March 7, 2014 9:47 PM
To: Andrei Popov; Salz, Rich; Alyssa Rowan; [email-masked]
Subject: Re: [Uta] On prohibiting RC4

Hi Andrei,

I'm not sure I understand your response. The way I parse it, in
*today's* Internet, assuming we never want to resort to cleartext, what would work is:

- Client initiates handshake #1 without RC4.
- Server (sometimes, if it's old) fails the handshake. This failure is unauthenticated, which means it can be forced by an attacker.
- client fallbacks to handshake #2 with RC4 (which by the way, is disallowed by the draft).
- Server's happy.

IMHO this would only complicate fallback logic (which in an ideal world we should have gotten rid of) without improving security.

If we're saying MUST NOT we must be able to stand behind it. If we can't, let's try to craft more nuanced language.

The current draft would fail the connection and thereby fallback to cleartext if the client only offers RC4. Even if such clients are rare, this is still a grave mistake IMO.

Thanks,
	Yaron