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

Paul Lambert <> Fri, 08 August 2014 21:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6A7FF1B27A6 for <>; Fri, 8 Aug 2014 14:21:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.267
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6sUDoVO4n8eg for <>; Fri, 8 Aug 2014 14:21:10 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 160EC1A0AD9 for <>; Fri, 8 Aug 2014 14:21:10 -0700 (PDT)
Received: from pps.filterd ( []) by (8.14.5/8.14.5) with SMTP id s78LL7wt009164; Fri, 8 Aug 2014 14:21:09 -0700
Received: from ([]) by 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 ([]) by ([]) with mapi; Fri, 8 Aug 2014 14:20:57 -0700
From: Paul Lambert <>
To: "" <>, "Blumenthal, Uri - 0558 - MITLL" <>
Date: Fri, 08 Aug 2014 14:20:54 -0700
Thread-Topic: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00
Thread-Index: Ac+zTqO0y6aeAm7kQNeCjAzXPK7ynw==
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
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
Cc: " (" <>
Subject: Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 Š ³


On 8/8/14, 2:09 PM, "Martin Rex" <> 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
> 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_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:
>they get merely the same throughput with AES-NI boosted AES-CBC cipher
>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
>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).
>TLS mailing list