Subject: [TLS] RC4 depreciation path (Re: Deprecating more (DSA?))

From: Watson Ladd <[email-masked]>
Date: Fri, 18 Apr 2014 23:03:44 -0700

On Thu, Apr 17, 2014 at 9:15 AM, Brian Sniffen <[email-masked]> wrote:
> Alyssa Rowan <[email-masked]> writes:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> It looks like RC4 is rapidly heading for the chopping block, with
>> basically unanimous consensus. Good.
>
> Agreed, mod Martin's proposal that I understand to ask for a reasonable
> path by which we strongly deprecate RC4 on clients, then after a client
> generation ban RC4 on clients and deprecate for servers.

I don't think this is the correct path. I think what we should do is
have clients and servers both prefer other options (in all TLS
versions), then once that change is made, ban it entirely. Deprecation
on one side won't affect the other side if there isn't an alternative
mandated. (Right now RC4 only servers are keeping RC4 alive).

This first step has already happened in the web context on modern
browsers. What we need is to make the server side step happen, and
then think about removal in the second step.

Sadly, our ability to force upgrades is very limited.

How long a client generation were you thinking? Because I could see
cryptanalysis speeding up: RC4 has been neglected for about 12 years
after WEP, but the new techniques of massive brute force coupled with
some good idea might bear fruit sooner than expected.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 19 Apr 2014 15:10:19 +0200

> Sadly, our ability to force upgrades is very limited.

And I think publishing an RFC isn't actually really going to help
much.  Yes, people could use it tell others that it's deprecated,
but I think there are already more than enough places that say so
that having this RFC isn't really going to make a difference.

I do agree that we need to try to get both sides to stop using it,
and I wish we could just tell people to stop using it and that
they would do so.  But I don't see either the server or the client
side wanting to break things.  It would clearly help if they could
say at which point they wouldn't mind breaking things.

So I think that for now the best we can do is:
- Servers should either stop accepting RC4 or make sure that 
  if the clients supports something better (TLS >= 1.1?) it should
  not pick RC4.
  It's my understanding that the client preferences of ciphers
  should be used but that servers can override that, and that
  there might be good reasons to do so. For instance to get PFS
  when talking to Internet Explorer.  If they override it, they
  should make sure not to put RC4 first.  Basically, a mondern
  client should never get RC4.
- Clients should not announce support for RC4 in their initial
  connection attempt, and only fall back to support it when the
  server says that there are no common ciphers.  (I'm not sure
  if a MITM can fake that response or not.)

At some point in time when the clients or servers think that they
don't need to support RC4 anymore they should disable it.

Kurt

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 19 Apr 2014 17:27:45 +0300

>   if a MITM can fake that response or not.)

MITM (or eavesdropper with packet injection capabilities) can
fake the response, there is no cryptographic verification.

-Ilari

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 19 Apr 2014 10:32:24 -0700

>   if a MITM can fake that response or not.)

Continue the handshake all the way through to the Finished messages
to determine if a MITM has tampered with it.  This will only not
work if the server is of the type that chooses RC4 no matter where
it is in the client's cipher suite list.

Here's the message flow I'm thinking about:

     ClientHello (w/o RC4)      ----->
                                <-----    Alert (handshake_failure)

close and reconnect:

     ClientHello (with RC4)     ----->
                                <-----    ServerHello (RC4 chosen)
                                          ..... continues

Place the RC4 suites at the end of the list so that the server will
not choose them if it respects the client's preference.

Mike

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 19 Apr 2014 19:53:52 +0200

> not choose them if it respects the client's preference.

Right, so an MITM could downgrade to RC4 in case the server
prefers RC4 over the rest in that case.

Kurt

---

From: Yoav Nir <[email-masked]>
Date: Sat, 19 Apr 2014 22:28:19 +0300

> prefers RC4 over the rest in that case.

Yes. As long as the client is required to support such servers, I guess we have to live with it.

It’s possible to make some kind of extension to help discover this activity by a MitM, but I don’t expect servers that continue to support RC4 to be the kind of servers that upgrade to the latest version of the software, the one that supports the new extension.

Yoav

---

From: Fabrice <[email-masked]>
Date: Sat, 19 Apr 2014 12:32:59 -0700

> On Apr 19, 2014, at 6:10, Kurt Roeckx <[email-masked]> wrote:
> 
> much.  

Not much, but a little bit. I think there are still a lot of people (including myself) that are not convinced that the severity of the attacks against RC4 justify removing it yet. I'm not an expert enough to be able to tell if the various published papers about RC4 are mostly theoretical issues, or practical ones. 

If the IETF comes out with an RFC officially deprecating it, that's one more thing telling me this is serious enough that it should really be looked at.

> Yes, people could use it tell others that it's deprecated,
> that having this RFC isn't really going to make a difference

> say at which point they wouldn't mind breaking things

>  if the clients supports something better (TLS >= 1.1?) it should

I would think there would be very few if any clients out there that only support RC4. But I would expect some servers out there do no support RC4 already.
Although I have no actual data to support my gut feeling here, and would be glad to be proven wrong. 

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Yoav Nir <[email-masked]>
Date: Sat, 19 Apr 2014 22:41:50 +0300

> If the IETF comes out with an RFC officially deprecating it, that's one more thing telling me this is serious enough that it should really be looked at.

+1

An RFC can help me convince management to let me make RC4 off by default.

Totally removing it from the product?  Probably not. On the IPsec side of it we still have “Export” ciphers like 40-bit DES, but making it off by default goes a long way towards making it not deployed.

Yoav

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 19 Apr 2014 21:54:34 +0200

> Although I have no actual data to support my gut feeling here, and would be glad to be proven wrong. 

IE on XP is known to only support 3DES, RC4, and some export
ciphers.  Not everybody agrees that 3DES would be best for those,
because 3DES is much slower.  3DES would probably be vulnerable
to BEAST, and IE6 doesn't like the record splitting.  If you
really need to support those clients RC4 might actually be your
best option.

I don't have any good stats about what clients our out there and
what they support, but I've hard mozilla is collecting some.  But
then I'd actually rather see stats from someone else.

For stats about servers, see:
https://www.trustworthyinternet.org/ssl-pulse/
https://jve.linuxwall.info/blog/index.php?post/TLS_Survey

Kurt

---

From: Watson Ladd <[email-masked]>
Date: Sat, 19 Apr 2014 12:57:11 -0700

> If the IETF comes out with an RFC officially deprecating it, that's one more thing telling me this is serious enough that it should really be looked at.

Have you seen the graphs of recovery probability against number of
connections? It's pretty bad.

The big idea is to use Fluherer-McGrew biases+Hidden Markov model
algorithms. That's assuming no more cryptanalysis results. I don't
think that's a good assumption.

> Although I have no actual data to support my gut feeling here, and would be glad to be proven wrong.

It's a server-side workaround for BEAST. Not all old IE versions have
1/n-1 record splitting. I'm part of the problem here: my dad refuses
to get a new computer, so IE6 on XP it is. However, old IE isn't
vulnerable without plugins.

Vanguard.com is a website using RC4 on modern browsers. The reason for
this is partly BEAST and partly a misconfiguration in which they
support TLS 1.2, but still want RC4. It's this sort of issue which we
can solve easily. Removing RC4 from browsers wouldn't break them.

---

From: Alyssa Rowan <[email-masked]>
Date: Sat, 19 Apr 2014 21:10:20 +0100

On 19/04/2014 20:28, Yoav Nir wrote:

> As long as the client is required to support such servers, I guess 
> we have to live with it.

I think the only correct deprecation path to recommend is the one
that's on the table right now: the off switch.

Warn your users if you have to. But don't negotiate RC4 without a
click-through warning.

RC4 is either on the brink of being cracked, given the serious known
weaknesses pointed out in Section 1 of the draft, or it is already
over the brink (if that's the 'cryptanalytic breakthrough' GCHQ were
talking about that they got from NSA, and that seems plausible to me,
and to several others, including Schneier).

If it's on the brink, then when it's cracked, captured traffic can
(and will) be retroactively decrypted. If it's over the brink, that's
already happening.

That window of opportunity was widened by advice given to use RC4-SHA
to avoid BEAST, which is why some servers prefer RC4 to AES-128. (That
was very bad advice, with 20:20 hindsight.)

We need to close that window now. As you've seen in this discussion,
there is only one safe way to close that window: disable RC4
completely. Any delay in disabling RC4 leaves that window open for
longer, and leaves users subject to a false sense of security about
their connections that should be protected by that little 'lock icon'.

I don't think we can in good conscience recommend any delay. That's
why the draft we have strong consensus on is crystal-clear:

   o  TLS clients MUST NOT include RC4 cipher suites in the ClientHello
      message.

   o  TLS servers MUST NOT select an RC4 cipher suite when a TLS client
      sends such a cipher suite in the ClientHello message.

   o  If the TLS client only offers RC4 cipher suites, the TLS server
      MUST terminate the handshake.  The TLS server MAY send the
      insufficient_security fatal alert in this case.

In short: RC4 is Considered Harmful. Kill it with fire.

On 19/04/2014 20:54, Kurt Roeckx wrote:

> ciphers.

Firstly, of those options, they're all bad. 3DES is the less awful
option in my opinion (because BEAST is an active attack, but RC4 is or
will be vulnerable to a passive attack applicable in retrospect), but
none of them are recommended.

But, reminder: support for Windows XP ended 11 days ago. It's now off
life-support... it's got bigger problems than even 3DES.

- -- 
/akr

---

From: Yoav Nir <[email-masked]>
Date: Sat, 19 Apr 2014 23:40:30 +0300

> https://jve.linuxwall.info/blog/index.php?post/TLS_Survey

Oh. Doing ephemeral diffie-hellman just to then use the results to encrypt with DES.  And over a quarter of the servers do this. I have to wonder how many of the (at least) 379 servers that support NULL ciphers actually meant it. Or of the 14% who support RC2.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 19 Apr 2014 23:50:41 +0300

> Warn your users if you have to. But don't negotiate RC4 without a

I can probably do it, as long as I provide a configuration to re-enable it. But that’s me. 

Check out the survey that Kurt posted a link to. 1.56% or TLS servers support only RC4. Browsers are distributed for free, and each of the big ones is installed in hundreds of millions of copies. They can’t afford having support calls, and they can’t afford the bad publicity that comes with “some sites don’t work with this browser”.  What Microsoft is doing is the best we can hope for for now.

Yoav

---

From: Watson Ladd <[email-masked]>
Date: Sat, 19 Apr 2014 14:07:28 -0700

> Check out the survey that Kurt posted a link to. 1.56% or TLS servers support only RC4. Browsers are distributed for free, and each of the big ones is installed in hundreds of millions of copies. T…

What happens 5 years from now when those servers still aren't updated?
I think the best we can do is stop configurations of new software from
supporting it.

Furthermore, we need to ensure that we never face this situation
again. RC4 needed to be depreciated starting with WEP. In the future
we will need to have much more aggressive depreciation, better
guidance on what to support and in what order to prefer ciphersuites.

Sincerely,
Watson Ladd

---

From: Alyssa Rowan <[email-masked]>
Date: Sat, 19 Apr 2014 23:41:14 +0100

> re-enable it. But that’s me.

Great. A good start. (Suggestion: Put a big fat warning on that config
option so no-one who re-enables it can say they didn't know what they
were getting into?)

> Check out the survey that Kurt posted a link to.

I'm well aware. Sorry state of affairs: so, what can we do here to
make it better? Maybe a little.

> 1.56% or TLS servers support only RC4.

Partly because of PCI compliance testers making noise about BEAST, I'm
thinking.

An RFC strongly deprecating RC4 can only help reduce that number:
those same PCI compliance testers can be pointed towards that as 'best
industry practice' - and may fail them for that? Their remaining
solution? Probably TLSv1.2 AES-GCM.

It _could_ work? I'm not saying it will, but it's the best option I
can come up with.

> they can’t afford the bad publicity that comes with “some sites 
> don’t work with this browser”.

What I'm suggesting is: Don't blame the browser. Blame the site. It's
the site that only wants to use a bad cipher. A warning lets you place
blame where it belongs, depending on how you frame it....

   "! The site uses insecure ciphers!

    You attempted to reach %s but the server only offered to use
    an insecure cipher, RC4. [RFCabcd, 2014] specifically warns that
    the RC4 cipher MUST NOT be used anymore, because it is dangerously
    weak.

    You should not proceed. If you proceed, an attacker could capture
    data that you send and read it in the future, including passwords
    and credit card numbers."

...blah blah, evil hackers will eat your babies etc. The point is, the
impression you want to give to the user is not "browser X throws up
errors with this site, shouldn't X fix it?", but "I'm seeing warnings
that site Y is insecure, shouldn't Y fix it?".

Of course, I'm being thoroughly idealistic here, assuming anyone ever
reads anything, no matter the colour or font size, and users won't
click through agreements for their mortal soul and give up their
passwords on the street to a woman with a clipboard for a Mars bar. <g>

The cynical side of me is more aware that browser veterans are
pragmatic, headdesk about this issue regularly and are used to
whatever changed most recently getting the blame for whatever happens,
no matter what.

That's why I'm suggesting a warning with an option to retry insecurely
rather than fail, or something kind of like that, but I'm broadly
aware of the difficulties they face. That's more a matter for them, of
course.

What we can do here is, well, what we _are_ doing. What we can.

- -- 
/akr

---

From: Jacob Appelbaum <[email-masked]>
Date: Sat, 19 Apr 2014 23:58:48 +0000

> and to several others, including Schneier).

I think that RC4 is completely broken for certain adversaries. It
should be totally abandoned.

> (and will) be retroactively decrypted. If it's over the brink, that's

Yes, I agree. I believe that this is already happening.

> In short: RC4 is Considered Harmful. Kill it with fire.

I agree entirely. RC4 needs to die in a fire. A celebratory TLS 1.3 fire.

All the best,
Jacob

---

From: [email-masked] (Martin Rex)
Date: Wed, 23 Apr 2014 02:14:48 +0200 (CEST)

> Partly because of PCI compliance testers making noise about BEAST, I'm

BEAST was and still is a pretty stupid hype.

Even the ssl test at qualys is still making bogus claims about
servers not being BEAST-patched.  Unless your server is a SSL-VPN server
or will boldly execute client-supplied active content, there can not
possibly be a BEAST vulnerability in the TLS server.

The larger problem with the use of RC4 is that a number of dense
TLS clients (e.g. Java) send RC4 cipher suites at the very beginning
of the list of cipher suites, and a number of dense TLS server
choose the first shared cipher from the list proposed by the client
rather then the first shared cipher from the list configured by the
server admin.

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Tue, 22 Apr 2014 21:09:47 -0700

> possibly be a BEAST vulnerability in the TLS server.

It's not about the server: if I only offer TLS 1.0, then clients who
connect to me who aren't 1/(n-1) patched are vulnerable to BEAST,
which leads to theft of credentials. Force RC4, and it isn't
exploitable, no matter how bad the client is. (BEAST was demonstrated
against PayPal on a fully patched browser, with cookies stolen live on
stage. I don't see how it is "stupid hype")

With modern clients this isn't a concern: TLS 1.1 or higher fixes the
problem, as does 1/(n-1). However, there are enough old clients out
there to apparently make this an issue, and the fix usually forces all
of them to RC4. The one saving grace is BEAST requires a plugin. So
far.

At some point RC4 needs to be removed. The question is now, or after
someone demonstrates the sort of attack that we have nightmares about.
Actually, given the talk about a removal path, 5 years from now or 3
years after someone demonstrates an attack.

> rather then the first shared cipher from the list configured by the

One side or the other needs patching, preferably both. End of the day
we can't do anything without some actual work getting done on deployed
stuff. But yes, this is a good reminder that not everything is a web
browser that calls home every week for an update.

Sincerely,
Watson Ladd

---

From: Alyssa Rowan <[email-masked]>
Date: Wed, 23 Apr 2014 06:53:21 +0100

On 23/04/2014 05:09, Watson Ladd wrote:

> At some point RC4 needs to be removed. The question is now, or 
> after someone demonstrates the sort of attack that we have 
> nightmares about. Actually, given the talk about a removal path, 5
> years from now or 3 years after someone demonstrates an attack.

The only correct response to a probably-broken cipher is to turn it
off _right now_ and replace it with something better (TLSv1.2
AES-128-GCM, say).

Unless you're doing SSL/TLS for purely decorative purposes, it is
preferable that insecure endpoints are unreachable or warned about -
and are fixed - than the very real hazard that people will _go back_
and decrypt all of your sensitive traffic.

> One side or the other needs patching, preferably both. End of the 
> day we can't do anything without some actual work getting done on 
> deployed stuff.

I see a draft like this as being the writing on the wall the slowpokes
need to start getting them moving; more importantly, the writing on
the wall that we can show their auditors.

- -- 
/akr

---

From: [email-masked] (Martin Rex)
Date: Wed, 23 Apr 2014 15:25:46 +0200 (CEST)

Watson Ladd wrote:
[ Charset UTF-8 unsupported, converting... ]
> which leads to theft of credentials.

So what?  The server isn't vulnerable to BEAST, and when the client
will blissfully execute any attacker-supplied content, then the
silly BEAST demonstration is of no interest at all.  As long as the
client keeps executing arbitrary attacker-supplied active content,
that active content can submit whatever nefarious requests it wants
to have performed on the server, and no amount of 1/(n-1) splitting
and TLSv1.2+AES-GCM can prevent that.

>
> Force RC4, and it isn't exploitable, no matter how bad the client is.
> (BEAST was demonstrated against PayPal on a fully patched browser,
>  with cookies stolen live on stage. I don't see how it is "stupid hype")

It wasn't a "fully patched" browser, it was a wide-open browser.

A fully patched browser would have *NO* active content plugins
(no java, no flash, no pdf, no media, no office, whatever) and
lots of other crap disabled (no scripting, no downloadable fonts, etc).

BEAST only demonstrated that Web Browsers, in the configuration that
they're shipping, are a *HUGE* security problem by themselves.

> problem, as does 1/(n-1).

It fixes the most irrelevant part of the BEAST prerequisites.

>
> However, there are enough old clients out there to apparently make
> this an issue, and the fix usually forces all of them to RC4.
> The one saving grace is BEAST requires a plugin. So far.

BEAST requires a willingness to execute attacker-supplied active content.

> years after someone demonstrates an attack.

Look at the rfc5746 (TLS extension renegotiation_info) adoption rate.
The necessary change was rather small and could be added to *ANY*
version of TLS.  Anything more complicated will take longer to get
deployed in the installed base.

For some vendors, it seems to be primarily a sales strategy issue to
deploy more complex TLS updates.  Microsoft never shipped support for
AES TLS cipher suites (rfc34268) for Windows XP, although this would
have been *trivial* for them.  They had shipped AES for XP with
KB917021 (WPA2 hotfix) in late 2006, and for Windows 2003 / XP 64-bit
they shipped an update with AES TLS cipher suites with KB948963 in 2008.

Hotfixes for secure renegotiation and the 1/(n-1) record splitting
were shipped for XP as well.

For some usage scenarios, record splitting like 1+1+1+1+1+1+1+1+1+1+1/(n-11)
might potentially help somewhat where the RC4 cipher suite can not be avoided.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Wed, 23 Apr 2014 17:07:07 +0200 (CEST)

> should be totally abandoned.

While I have heard claims that RC4 would be "completely broken", I am
still not aware of the slightest indication why or how this break
would be performed.

RC4 is a stream cipher, and operates by xoring plaintext with
a pseudo-random keystream.  In order to "completely break" RC4,
it would be necessary to precompute future RC4 outputs from
some amount of *known* RC4 keystream, essentially re-creating
the internal state of the RC4 algorithm.

HTTP is a protocol with often quite a lot of known plaintext,
so recovering *some* amount of RC4 keystream will often be possible
with a low probability of error.  So that leaves us with the questions

  - are parts of the RC4 algorithm invertible?
  - is it possible to recreate the RC4 internal state from a certain
    amount of keystream octets.
  - how many keystream octets would be necessary
  - will those known keystream octets have to be from specific locations
    (or consecutive)
  - how big is the workfactor?

I'm _not_ saying that this hasn't happened.  But without the slightest
indication about a _real_ problem with the RC4 algorithm internals,
I refuse to be terrorized.

-Martin

PS: the most attractive target for breaking is the key exchange algorithm,
because that would make the traffic protection keys (MAC and encrypt)
available independent of the crypto an mac algorithms and their strength.
Considering that NSA has been pushing ECDSA+ECDHE for quite a while
(Suite B with NIST curves), I'm more worried about EC weaknesses than
RC4 bias or chained CBC-IVs.

ECDHE with Curve25519 and single-use(!!) DHE keypairs looks OK, but
that might not interoperable with a large fraction of the installed
base for another decade.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 23 Apr 2014 08:54:05 -0700

> the internal state of the RC4 algorithm.

Yes, that would be terribly bad of a break. We don't have one like
that now. 5 years from now I would not be surprised. We need to start
moving now to be ready for the inevitable. I would prefer not to have
my banking secrets spread across the Internet before we decide we have
a problem.

However, even before you predict keystream from a handful of bytes you
can do the following:
-Use multiple connections sharing similar data together with hidden
markov models to recover text
-Use byte biases to determine what kind of information is flowing into
and out of a server: yes we can tell if you have binaries or text and
serve them up over RC4.
-Remember wepcrack? RC4 leaks key information

The RC4 state update is weak: it always changes an even permutation to
an odd one. There are probably other rep theoretic issues: I've not
thought very hard about it.

All of this is possible today. It won't stop being possible, and our
understanding of the weaknesses in RC4 will only grow. Already, users
assumptions of the security they have is not met by RC4.

Given uptake times, we need to start pushing for a fix now if we want
it ready in 5 years. Supposedly, algorithm agility was supposed to
work for this eventuality: it should be relatively trivial to change
configurations to use block ciphers if you don't care about BEAST and
Lucky 13. If you do, upgrade to TLS 1.2. We have a fix: it needs to be
deployed, and people need to know they have to.

> RC4 bias or chained CBC-IVs.

You shouldn't be. EC has been around since 1985 with no real
scratches. Do you know something we don't? Show me a discrete log on
P256 (with all the usual points about how to do it so I know you
didn't cheat) and I'll get worried. Show me a new weak class of curves
(prime fields only) and I'll be interested.

> that might not interoperable with a large fraction of the installed

Single-use only because implementors don't take elementary precautions
against side channels. The Curve25519 impl. has no side-channels.
The security difference between Curve25519 and P256 is entirely a
result of poor implementations. The speed difference is a result of
careful choices.

There is no known attack against properly implemented Suite B
protocols known in the open literature. Nor is there likely to be one
anytime soon: extensive analysis over the past decades has found
nothing. However, implementation quality can be low.

Sincerely,
Watson Ladd

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 23 Apr 2014 17:48:23 +0000

>might potentially help somewhat where the RC4 cipher suite can not be

No, this doesn't help, because of the double byte bias attacks. Moreover,
the interesting content (from the attacker's perspective) is rarely in the
first few bytes of the TLS connection. For an analysis of this and other
"countermeasures" to the RC4 attacks, please read the paper at:

http://www.isg.rhul.ac.uk/tls/RC4biases.pdf

especially Section 7.

Cheers

Kenny

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 23 Apr 2014 18:06:38 +0000

>> still not aware of the slightest indication why or how this break

Me neither. 

Jacob Applebaum has said this kind of thing in various fora. I think it's
time he put some detail behind the claim (or stopped making it).

However, whether this is correct or not does not diminish the other
well-justified arguments for deprecating RC4. It's looking distinctly
unwell to me.

>markov models to recover text

Indeed, the use of language models is mentioned as an enhancement in our
paper. Based on my experience of using such models in a different context,
I think they would make a big difference in reducing the attacks'
ciphertext requirements when the plaintext being targeted is "natural
language", and possibly even passwords. But this is less likely to be
effective for session cookies. It would be a great student project to
investigate this angle.

>and out of a server: yes we can tell if you have binaries or text and

I don't immediately know how you'd do that, but I'm willing to be
educated! Maybe you're assuming ASCII or binary plaintext, and then
aggregating most significant bit estimates over many ciphertext positions?
Do you have an estimate for how much ciphertext would be needed to achieve
a certain confidence level here?

>-Remember wepcrack? RC4 leaks key information

Right now, we do not know how to exploit key leakage into the keystream
when RC4 is used in TLS. To understand why, you have to look at how the
RC4 key for each session/connection is computed in TLS compared to how it
is computed for each frame in WEP. If you can make progress here, then you
would have a very nice research paper (and probably an improved attack on
RC4 in TLS).

>thought very hard about it.

But then it's unwise to speculate, Watson! By contrast, many people have
studied RC4 fairly intensively over the years, and the state of the art is
what it is (modulo claims by Jacob Applebaum). I'd recommend you either do
think about RC4 hard, or go read the literature, rather than just
speculating.

>assumptions of the security they have is not met by RC4.

I can almost agree with this, except for your comments about key leakage
into the keystream.

Cheers,

Kenny

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 23 Apr 2014 14:12:34 -0400

Thanks for posting; it's great to have a cryptographer weigh in.

So, at the risk of putting you on the spot:  what do you think we (TLS-WG) should do?

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]; Twitter: RichSalz

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 23 Apr 2014 18:15:50 +0000

>So, at the risk of putting you on the spot:  what do you think we

I think we should deprecate RC4 now, in the hope that in the medium term,
we can reduce the amount of RC4 being negotiated in TLS.

As others have said, the RFC, if published, gives a useful stick with
which to beat the appropriate people/argue for change.

Cheers

Kenny

---

From: Yoav Nir <[email-masked]>
Date: Wed, 23 Apr 2014 22:24:27 +0300

> which to beat the appropriate people/argue for change.

I agree. Just let’s not overestimate our influence. In January 1999 RFC 2459 said this:

   Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5,
   but there are no other known cryptanalytic results.  The use of MD5
   for new applications is discouraged.  It is still reasonable to use
   MD5 to verify existing signatures.

10 years later it turned out that some public CAs (not just RapidSSL) were signing new certificates with MD5.

Yoav

---

From: David Holmes <[email-masked]>
Date: Wed, 23 Apr 2014 19:28:14 +0000

> I think that RC4 is completely broken for certain adversaries. It should be totally abandoned.

Like Martin, I too am wondering if there was some RC4 attack I'm not aware of that is causing people to say it's "completely broken". Last I heard the best attack still had a 2^24 message requirement. Ciphers appear to have relative strength over time; absolute statements like "completely broken" work against the ability to weigh ciphers as options in a given threat environment over time.

---

From: Bill Frantz <[email-masked]>
Date: Wed, 23 Apr 2014 12:36:04 -0700

>browser that calls home every week for an update.

Should we have a best practices standard for the Internet of 
Things (IoT) which provides for updating their cryptography? If 
we do, we'll quickly get into the bind of function vs. cost. If 
we don't, we probably will see LED bulbs, with their 20+ year 
life span, which are vulnerable to unauthorized control and 
therefor must be run on a closed network. That configuration 
will require a gateway through a more capable, and frequently 
updated, machine. If the LEDs are controlled through their power 
connection it will also require power line isolation. This last 
suggestion may be a nightmare for the IoT dreamers.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Truth and love must prevail  | Periwinkle
(408)356-8506      | over lies and hate.          | 16345 
Englewood Ave
www.pwpconsult.com |               - Vaclav Havel | Los Gatos, 
CA 95032

---

From: Geoffrey Keating <[email-masked]>
Date: 23 Apr 2014 13:40:44 -0700

Yoav Nir <[email-masked]> writes:

> I agree. Just lets not overestimate our influence. In January 1999 RFC 2459 said this:
> 

Yes, but look at the full part of the glass: 10 years later almost all
CAs were *not* signing new certificates with MD5, which made the
cleanup & recovery much easier.

Imagine if today, the major web browser vendors turned off RC4
support.  Sure, in a year there'd probably still be 50% of the web
vulnerable, but the other 50% would be safe... and in 3 years, it'd be
20% vulnerable, and they'd probably still be running XP anyway :-).

---

From: [email-masked] (Martin Rex)
Date: Wed, 23 Apr 2014 23:02:43 +0200 (CEST)

Paterson, Kenny wrote:
>
> "Watson Ladd" <[email-masked]> wrote:
>>
>> Martin Rex <[email-masked]> wrote:
>>> 

Quantify "multiple connections sharing similar data" /
the attacks' ciphertext requirements.

I'm doing like 300 web-based purchases with OTP-authentication tokens
(TAN) year and maybe 4 Credit Card purchases per year online from various
different shops and would repeat a single failing purchase at most 5 times
before I would give up.

The numbers I've seen so far do not scare me for a significant number
of usage scenarios.  That doesn't mean that there would be no usage
scenarios where the weaknesses could be sufficient to make an attack
practical.  But I'm not using any of those.

Problems like the recent shortcut in the certificate validation
for (EC)DHE cipher suites in Apple's TLS stack and GnuTLS, or the
recent Heartbleed (Heartbloat) attack is stuff that worries me much more.

-Martin

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 23 Apr 2014 21:32:07 +0000

>the attacks' ciphertext requirements.

Sure, I'll be able to quantify it for you just as soon as I've done the
research. Someone with better coding skills than me could probably knock
something up in a day or two, but I'm not that guy.

>practical.  But I'm not using any of those.

Perhaps you are not, but people who use your company's systems may be (but
then you don't consider the use of client side javascript to recover
session cookies to be an attack, right?)

>recent Heartbleed (Heartbloat) attack is stuff that worries me much more.

I completely agree. But both of these specific problems are much easier to
solve, once identified, than removing RC4 support seems to be.

By the way, it seems SAP relies on OpenSSL in at least some of its
products [1]. Hope your company is planning on making a big donation to
the OpenSSL foundation real soon now :-)

Cheers

Kenny

[1] 
http://scn.sap.com/community/bi-platform/blog/2014/04/11/sap-business-intel
ligence-and-the-openssl-heartbleed-vulnerability

---

From: Marsh Ray <[email-masked]>
Date: Wed, 23 Apr 2014 23:14:41 +0000

-----Original Message-----
From: Martin Rex
Sent: Wednesday, April 23, 2014 8:07 AM
>  - are parts of the RC4 algorithm invertible?

Yes, in the sense that knowledge of the ~1600 bit state allows one to determine forward *and backwards* in the stream.

This was done for WEP, which is particularly pathological in the way it uses the raw password as the key. 

TLS uses a unique 128 bit PRF-derived key on every handshake. I haven't heard of anyone being able to attack this method of keying.

> - how many keystream octets would be necessary

(Speculation) At least 1600/8 = 200 bytes or so.

    (or consecutive)

Known attacks rely on specific locations.

(Speculation) Other attacks probably would benefit from specific locations, but would probably not require perfectly contiguous known plaintext.

>  - how big is the workfactor?

Who knows?

> I'm _not_ saying that this hasn't happened.  But without the slightest indication
> about a _real_ problem with the RC4 algorithm internals, I refuse to be terrorized.

There are real, known attacks on the RC4 algorithm internals, even with the solid keying as used by TLS.

> PS: the most attractive target for breaking is the key exchange algorithm, because
> that would make the traffic protection keys (MAC and encrypt) available
> independent of the crypto an mac algorithms and their strength.

That doesn't mean the cipher won't be attacked *too* :-)

- Marsh
-----------------------------------
Usual boilerplate disclaimers apply.

---

From: [email-masked] (Martin Rex)
Date: Thu, 24 Apr 2014 03:16:54 +0200 (CEST)

Watson Ladd wrote:
> Martin Rex wrote:

I'm sorry, but theoretical results mean nothing to me.  For me,
the quality of real-world implementations is what really counts,
and there have been several quite epic failures with (EC)DSA
which are *nowhere* clear from the specification.

One of these severe problems is still present in FIPS 186-4.

(EC)DSA is the cryptoglycerin among cryptographic algorithms,
with casualties all over the place.

-Martin