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

From: Sean Turner <[email-masked]>
Date: Fri, 8 Aug 2014 08:52:26 -0400

This is the working group last call for draft-ietf-tls-prohibiting-rc4-00:
  http://datatracker.ietf.org/doc/draft-ietf-tls-prohibiting-rc4/
Please send comments on this draft to the TLS list before August 23, 2014.

J&S

---

From: [email-masked] (Martin Rex)
Date: Fri, 8 Aug 2014 15:36:28 +0200 (CEST)

> Please send comments on this draft to the TLS list before August 23, 2014.

The RC4 cipher suites are still stronger than the EXPORT40 and EXPORT56
cipher suites, because for the latter, even one singular session can
be successfully attack and *completely decrypted* in most cases, whereas
the weaknesses currently known for RC4 cipher suites allow an attacker
to recover only the plaintext equivalent of a static
"disclosing authentication" (password or token) after 2^20+ TLS session.

I therefore object to the Bullets 2 & 3 of section 2,
(I'm OK with bullet 1):

   2.  Changes to TLS

     Because of the deficiencies noted in Section 1:

     o  TLS clients MUST NOT include RC4 cipher suites in the ClientHello
        message.

     o  TLS servers MUST NOT select an RC4 cipher suite when a TLS client
        sends such a cipher suite in the ClientHello message.

     o  If the TLS client only offers RC4 cipher suites, the TLS server
        MUST terminate the handshake.  The TLS server MAY send the
        insufficient_security fatal alert in this case.

It should be left to the local policy of the server whether to agree
to the use of an RC4 cipher suite rather than fail the connection.

Servers should NEVER let the client-side ordering of cipher suites
in ClientHello take precedence over the servers' preference,
and RC4 cipher suites, similar to EXPORT40 and EXPORT56 cipher suites
should never take precedence over stronger cipher suites that client
and server have in common, just because they happen to appear earlier
in the list in ClientHello.

Especially in the Web, where access to information is often available
through HTTP and HTTPS, a policy like the above (when adopted) would
cause MORE communication to be performed in plaintext.

There currently exists *no* known attack against the integrity
protection of the TLS handshake, so this looks primarily like an
attempt to promote "planned obsolesence", and a poor excuse for
Microsoft to actively break interop with Windows XP (and potentially
other installed base).

-Martin

---

From: Alyssa Rowan <[email-masked]>
Date: Fri, 08 Aug 2014 14:49:39 +0100

>Microsoft to actively break interop with Windows XP (and potentially

(Apologies if this brief message comes across abrupt/rude, as I'm pressed for time right now. Please infer due respect.)

Strongly disagree with your proposed change Martin, which fundamentally goes against the wide MUST NOT use RC4 consensus already confirmed in previous calls. I feel the draft language should stay just as it is.

Given the discussions and meetings already supporting that consensus, I have to ask: why are you proposing this big change so late in support of *any* continued use of a known-weak cipher?

XP is out of support and should definitely not be considered as a blocker.

- --
/akr

---

From: Hubert Kario <[email-masked]>
Date: Fri, 8 Aug 2014 09:59:09 -0400 (EDT)

----- Original Message -----
> From: "Martin Rex" <[email-masked]>
> To: "Sean Turner" <[email-masked]>
> Cc: "[email-masked] ([email-masked])" <[email-masked]>
> Sent: Friday, 8 August, 2014 3:36:28 PM
> Subject: Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00
> 

> cause MORE communication to be performed in plaintext.

according to CloudFlare[0] basically no web clients support just RC4.
During their test 0.0009% of visitors connected using RC4 after their
servers placed RC4 last in the cipher order.

> Microsoft to actively break interop with Windows XP (and potentially

3DES remains an option if you need to interoperate with very old
systems. It doesn't break interoperability with Windows XP.

 0 - http://blog.cloudflare.com/killing-rc4-the-long-goodbye
 
-- 
Regards,
Hubert Kario

---

From: [email-masked] (Martin Rex)
Date: Fri, 8 Aug 2014 16:56:58 +0200 (CEST)

>  0 - http://blog.cloudflare.com/killing-rc4-the-long-goodbye

This is the theory.
In theory, theory an practice are the same, in practice they differ.

There seems to be stuff that breaks with TLS cipher suites that
use padding.  This is just Windows stuff, 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.

-Martin

---

From: Hubert Kario <[email-masked]>
Date: Fri, 8 Aug 2014 11:23:10 -0400 (EDT)

----- Original Message -----
> To: "Hubert Kario" <[email-masked]>
> Cc: [email-masked], "Sean Turner" <[email-masked]>, "[email-masked] ([email-masked])" <[email-masked]>
> Sent: Friday, 8 August, 2014 4:56:58 PM

Those are bugs, if you _need_ to work around them, then work around them,
that's what MUST means.

But don't deploy those workarounds unless you're:
 1). sure that they are needed
 2). sure that this is the only way to workaround the issue

-- 
Regards,
Hubert Kario

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Fri, 8 Aug 2014 17:14:40 +0000

>...........I've also seen such

Could you please provide more information on this? What exactly did not
interoperate? And details, please?

Thanks!

---

From: [email-masked] (Martin Rex)
Date: Fri, 8 Aug 2014 23:09:02 +0200 (CEST)

> 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/open-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

---

From: Paul Lambert <[email-masked]>
Date: Fri, 8 Aug 2014 14:20:54 -0700

+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" <[email-masked]> wrote:

>_______________________________________________
>TLS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tls

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 18 Aug 2014 22:32:55 +0200

> ³ Š clients MUST NOT include RC4 cipher suites Š ³

+1. RC4 needs to go. Urgently.

The suggested change can - sorry - only be described as malicious. I've
seen not one solid reason in this thread to keep RC4 alive, and cannot
think of any reason today.

Aaron