Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00

Paul Lambert <paul@marvell.com> Fri, 08 August 2014 21:21 UTC

Return-Path: <paul@marvell.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 6A7FF1B27A6 for <tls@ietfa.amsl.com>; Fri, 8 Aug 2014 14:21:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Level:
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 6sUDoVO4n8eg for <tls@ietfa.amsl.com>; Fri, 8 Aug 2014 14:21:10 -0700 (PDT)
Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 160EC1A0AD9 for <tls@ietf.org>; Fri, 8 Aug 2014 14:21:10 -0700 (PDT)
Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s78LL7wt009164; Fri, 8 Aug 2014 14:21:09 -0700
Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0a-0016f401.pphosted.com with ESMTP id 1nm87curp3-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 08 Aug 2014 14:21:09 -0700
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Fri, 8 Aug 2014 14:20:57 -0700
From: Paul Lambert <paul@marvell.com>
To: "mrex@sap.com" <mrex@sap.com>, "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>
Date: Fri, 8 Aug 2014 14:20:54 -0700
Thread-Topic: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00
Thread-Index: Ac+zTqO0y6aeAm7kQNeCjAzXPK7ynw==
Message-ID: <D00A8C47.488E5%paul@marvell.com>
References: <D00A7D64.189DD%uri@ll.mit.edu> <20140808210902.8E0471ADFC@ld9781.wdf.sap.corp>
In-Reply-To: <20140808210902.8E0471ADFC@ld9781.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.3.140616
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-08-08_05:2014-08-08,2014-08-08,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1408080253
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RnhTS9h7ZYOXowyfe20T7Cp-Jzg
Cc: "TLS@ietf.org \(tls@ietf.org\)" <tls@ietf.org>
Subject: Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00
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: Fri, 08 Aug 2014 21:21:12 -0000

+1 on strongly disagree

Not sure how example below is relevant to total removal of RC4.

It¹s important to maintain the clear position that is in current draft:
³ Š clients MUST NOT include RC4 cipher suites Š ³


Paul

On 8/8/14, 2:09 PM, "Martin Rex" <mrex@sap.com> wrote:

>Blumenthal, Uri - 0558 - MITLL wrote:
>>>...........I've also seen such
>>>interop problems with Java (J2SE) client (using nio it seems),
>>>that will simply not interop with 3DES-EDE (nor AES128-SHA),
>>>and RC4 is the only alternative that works.
>> 
>> Could you please provide more information on this? What exactly did not
>> interoperate? And details, please?
>
>
>I know very little about Java, so I'll try to describe what happened.
>
>A partner had writen some data aggregation tool in Java (with JBoss,
>I believe) that was trying to submit that data as XML/SOAP via HTTPS
>to our backend server, but they were encountering TLS handshake failures.
>
>Our server was aborting the handshake with a fatal bad_mac(20) alert.
>The error message that the partner saw when debugging his java client
>was:
>
>   javax.net.ssl.SSLException: Received fatal alert: bad record mac
>
>I gave them a special debug build of our our SSL implementation that
>had all "countermeasures" (bleichenbacher,vaudenay) disabled and
>it turned out that the Java SSL client was sending bogus Finished
>handshake message records (decryption resulted in random garbage,
>including the padding value).  Since the Java client offered
>AES128-SHA, our server would choose that (server preference).
>
>The Java client was sending the following cipher suites in ClientHello:
>(26 cipher suites, EMPTY_RENEGOTIATON_INFO_SCSV included, head only ):
>
>  TLS_RSA_WITH_RC4_128_MD5          (0x0004)
>  TLS_RSA_WITH_RC4_128_SHA          (0x0005)
>  TLS_RSA_WITH_AES_128_SHA          (0x002f)
>  TLS_DHE_RSA_WTIH_AES_128_CBC_SHA  (0x0033)
>  TLS_DHE_DSS_WITH_AES_128_CBC_SHA  (0x0032)
>  TLS_RSA_WTIH_3DES_EDE_CBC_SHA     (0x000a)
>  TLS_DHE_RSA_WITH_3DES_ECE_CBC_SHA (0x0016)
>  TLS_DHE_DSA_WITH_3DES_ECE_CBC_SHA (0x0013)
>  TLS_RSA_WITH_DES_CBC_SHA          (0x0009)
>
>>From that list our server will pick the 3rd in its default configuration.
>
>So I suggested to them thre  tests with our server, limiting
>our server's ciper suite to (1) AES128-SHA, (2) 3DES-EDE-SHA, (3) RC4-128,
>and the test with AES128 and 3DES failed with bad-mac, whereas the test
>with RC4-128 succeeded.
>
>Then I asked them to try handshaking with an openssl s_server in similar
>configurations, and the results were the same: bad_mac for the cipher
>suites that were using CBC ciphers, success for RC4-128
>
>>From what I remember, they were using J2EE 1.6
>
>
>I do not know what part of the partner's software or the underlying
>Java J2EE is causing these problems.  But with the RC4 ciphers first
>in the Java's ClientHello and the bad habit of several TLS
>implementations to yield to the clients ordering rather than using
>the servers preference, the bug causing this interop problem may be
>rather old have gone unnoticed for a long time.
>
>
>The issue with 3DES is that it is *SLOW*.  much much slower than RC4-128.
>
>If you look at Intels paper about improving openssl AES ciper suites
>with AES-NI hardware support here:
>  
>http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/o
>pen-ssl-performance-paper.pdf
>
>they get merely the same throughput with AES-NI boosted AES-CBC cipher
>suites
>as they get with plain old RC4-128.
>
>
>RC4 cipher suites are a problem when applications on top use a disclosing
>authentication scheme in the clear with an authentication token or
>password
>that is valid essentially forever, and when clients can either be coerced
>to send this disclosing authentication several million times (or do this
>all by themselves).
>
>
>-Martin
>
>_______________________________________________
>TLS mailing list
>TLS@ietf.org
>https://www.ietf.org/mailman/listinfo/tls