Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path)

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Wed, 23 April 2014 21:32 UTC

Return-Path: <Kenny.Paterson@rhul.ac.uk>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C63F1A0537 for <tls@ietfa.amsl.com>; Wed, 23 Apr 2014 14:32:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJAP23TOsVsF for <tls@ietfa.amsl.com>; Wed, 23 Apr 2014 14:32:19 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 57F251A0654 for <tls@ietf.org>; Wed, 23 Apr 2014 14:32:19 -0700 (PDT)
Received: from mail51-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE020.bigfish.com (10.43.70.77) with Microsoft SMTP Server id 14.1.225.22; Wed, 23 Apr 2014 21:31:10 +0000
Received: from mail51-ch1 (localhost [127.0.0.1]) by mail51-ch1-R.bigfish.com (Postfix) with ESMTP id C3E2B340300; Wed, 23 Apr 2014 21:31:10 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.248.5; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0310HT004.eurprd03.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -4
X-BigFish: PS-4(zzbb2dI98dId772h1432I1453Izz1f42h1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1de098h17326ah8275bh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26d3h1155h)
Received-SPF: pass (mail51-ch1: domain of rhul.ac.uk designates 157.56.248.5 as permitted sender) client-ip=157.56.248.5; envelope-from=Kenny.Paterson@rhul.ac.uk; helo=AMSPRD0310HT004.eurprd03.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019001)(6009001)(428001)(51704005)(24454002)(52034003)(479174003)(199002)(189002)(83506001)(86362001)(80976001)(2656002)(15202345003)(46102001)(31966008)(74662001)(81342001)(79102001)(20776003)(80022001)(87936001)(4396001)(83072002)(76482001)(85852003)(76176999)(50986999)(77982001)(77096999)(74502001)(19580395003)(92726001)(19580405001)(99396002)(92566001)(83322001)(36756003)(15975445006)(54356999)(551544002)(74482001)(66066001)(81542001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR03MB383; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:DEDCF2D4.97F2AD11.7ED91EFB.EE57051.20490; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Received: from mail51-ch1 (localhost.localdomain [127.0.0.1]) by mail51-ch1 (MessageSwitch) id 1398288668558529_28757; Wed, 23 Apr 2014 21:31:08 +0000 (UTC)
Received: from CH1EHSMHS015.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail51-ch1.bigfish.com (Postfix) with ESMTP id 84C962007C; Wed, 23 Apr 2014 21:31:08 +0000 (UTC)
Received: from AMSPRD0310HT004.eurprd03.prod.outlook.com (157.56.248.5) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 23 Apr 2014 21:31:08 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by AMSPRD0310HT004.eurprd03.prod.outlook.com (10.255.40.39) with Microsoft SMTP Server (TLS) id 14.16.435.0; Wed, 23 Apr 2014 21:32:08 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) with Microsoft SMTP Server (TLS) id 15.0.921.12; Wed, 23 Apr 2014 21:32:07 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.00.0921.000; Wed, 23 Apr 2014 21:32:07 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: "mrex@sap.com" <mrex@sap.com>
Thread-Topic: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path)
Thread-Index: AQHPXCtzaRoqs6xj002Wq6Mdi5x8AJsfUwuAgAANH4CAADXHgIAAIHWAgAAY7wA=
Date: Wed, 23 Apr 2014 21:32:07 +0000
Message-ID: <CF7DEB2C.1C50D%kenny.paterson@rhul.ac.uk>
References: <CF7DBB70.1C4C6%kenny.paterson@rhul.ac.uk> <20140423210243.B43451ACDD@ld9781.wdf.sap.corp>
In-Reply-To: <20140423210243.B43451ACDD@ld9781.wdf.sap.corp>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.1.140326
x-originating-ip: [80.42.211.108]
x-forefront-prvs: 01901B3451
Content-Type: text/plain; charset="us-ascii"
Content-ID: <EB2DBCC24F526C469E5C7B66FDA5174D@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_SERDvcNJzkysioTM4CkqC0eG3U
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Apr 2014 21:32:23 -0000

On 23/04/2014 22:02, "Martin Rex" <mrex@sap.com> wrote:

>Paterson, Kenny wrote:
>>
>> "Watson Ladd" <watsonbladd@gmail.com> wrote:
>>>
>>> Martin Rex <mrex@sap.com> wrote:
>>>> 
>>>> 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.
>>>
>>>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
>> 
>> 
>> 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.
>
>Quantify "multiple connections sharing similar data" /
>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.

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

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?)

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

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