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

mrex@sap.com (Martin Rex) Mon, 14 April 2014 21:33 UTC

Return-Path: <mrex@sap.com>
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 A1CB21A0671 for <tls@ietfa.amsl.com>; Mon, 14 Apr 2014 14:33:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.852
X-Spam-Level:
X-Spam-Status: No, score=-3.852 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 5Tn1uES2d5BJ for <tls@ietfa.amsl.com>; Mon, 14 Apr 2014 14:33:13 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 31C621A0231 for <tls@ietf.org>; Mon, 14 Apr 2014 14:33:13 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s3ELX9gf020521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Apr 2014 23:33:09 +0200 (MEST)
In-Reply-To: <CABcZeBOvxL7Zws0UNowViBWGaVBgfm3zXt8=dNPKffGfN3q2gA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 14 Apr 2014 23:33:09 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140414213309.0F4821ACBF@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5siTGo8bowJBilnblpGTQ0iKMcQ
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Mon, 14 Apr 2014 21:33:17 -0000

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


This document does not provide any rationale for "prohibiting" RC4.

I'm not aware of any information that RC4 is "broken".  As noted in
the security consideration section of rfc6229, the RC4 keystream has
a small bias that might enable statistical plaintext recovery attacks
if the _exact_same_data_ is RC4-encrypted at the _exact_same_positions_
many many times.

There might be (higher layer) protocols that do this all by themselves
(resend the very same data over and over again) potentially including
credentials of a disclosing authentication, and there might be
communication peers that can be enticed to do this (such as web browsers).

-Martin


PS: I recently analyzed a customer problem report with a Java SSL 1.6 client
(JBoss) failing interop with our server.  The client's Finished message
decrypted into garbage with CBC cipher suites.

It could be that there is an interop problem in Java SSL clients
(Sun/Oracle's SSL 1.6 client) with block cipher based cipher suites.
The Sun/Oracle SSL 1.6 client sends RC4_128 first in the list, and if
our server was configured to prefer RC4_128 over AES128_CBC, then
the interop problem would not occur.  The 3DES_EDE_CBC cipher suite
also failed interop.  A quick test with OpenSSL confirmed that the
Sun/Oracle Java client was botching the CBC cipher suite handshakes.