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

[Paul Lambert <[e-mail]>]

+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" <[e-mail]> 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tls