Subject: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

From: [email-masked]
Date: Wed, 01 Oct 2014 16:12:54 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the IETF.

        Title           : Prohibiting RC4 Cipher Suites
        Author          : Andrei Popov
	Filename        : draft-ietf-tls-prohibiting-rc4-01.txt
	Pages           : 5
	Date            : 2014-10-01

Abstract:
   This document requires that Transport Layer Security (TLS) clients
   and servers never negotiate the use of RC4 cipher suites when they
   establish connections.  This applies to all TLS versions, and updates
   [RFC5246], [RFC4346], and [RFC2246].

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-prohibiting-rc4/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-prohibiting-rc4-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-prohibiting-rc4-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: [email-masked] (Martin Rex)
Date: Thu, 2 Oct 2014 02:58:04 +0200 (CEST)

[email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> 

The list of cipher suites in that document should better include
the cipher suite code points!  The code points are unique and unambiguous,
whereas the artificial symbolic names vary greatly among implementations

-Martin

PS: I still object to the MUST fail requirement to the server.
    It is not just plain silly it is also incompatible with
    rfc2119 section 6.  In many situations, the risk in accepting
    a TLS session with RC4 as a last resort for interop will be
    quite managable and pretty close to negligible.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 1 Oct 2014 18:23:47 -0700

> whereas the artificial symbolic names vary greatly among implementations

The symbolic names are in the IANA registry alongside the codepoints,
and are easier to transcribe correctly. These are not implementation
dependent.

Sincerely,
Watson Ladd

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

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 1 Oct 2014 20:33:01 -0500

>     quite managable and pretty close to negligible.

Agree.

--  
Principal Security Engineer, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Alyssa Rowan <[email-masked]>
Date: Thu, 02 Oct 2014 09:01:29 +0100

>PS: I still object to the MUST fail requirement to the server.

Objection from you and Rich noted, but I really do not agree. This draft absolutely must not be watered down. We should treat weak crypters as broadly equivalent to NULL. That is what this does.

I think fallback to RC4 is an insecure practice that we must not continue to condone. We have several strong ciphers, some with better performance, and we've known that RC4 was a tad wobbly for years: quite frankly the time for compatibility fallbacks and gentle transitions was 5 years ago or something and is now quite firmly passed. At this point, RC4 is a shambling undead zombie of an old 1980s 8086 crypter. Kill it with fire; stake it in the heart; bury it at a crossroads and dance on its gravestone.

And I think that we have reached WG consensus on that point broadly, despite your objections: as there is widespread recognition I think that if we do continue to sanction RC4's use for any reason, that will be the reason we'll never get rid of the damned thing (because people like you and Rich will keep accepting it when presented, to keep your clients with XP and prehistoric Android happy, but that unfortunately also makes Eve happy).

Anyone is entirely free to ignore confidentiality if they don't judge it's important in their scenario - but that doesn't mean it's a good idea for the internet at large, or that they weren't warned about the risk and chose to use it anyway.

>The list of cipher suites in that document should better include the cipher suite code points!

I do agree with this point, it would make it a little clearer and more unambiguous.

Subject to perhaps adding the ciphersuite codepoints, +1 for this draft.

- --
/akr

---

From: Hanno Böck <[email-masked]>
Date: Thu, 2 Oct 2014 10:26:02 +0200

Am Wed, 01 Oct 2014 16:12:54 -0700
schrieb [email-masked]:

>    establish connections.  This applies to all TLS versions, and
> updates [RFC5246], [RFC4346], and [RFC2246].

I really don't want to hold anything here and would welcome if this
gets finally out, however there's one thing that bothers me:
There is currently no such RFC for RC2 or DES. Both are - considering
current RFCs - perfectly valid ciphers according to RFC 2246.

It doesn't really make sense to forbid RC4 (likely weak, but no
public practical attacks yet) while still allowing RC2(40 bit)/DES
(practically broken).

Should we change this to "forbid RC2, DES and RC4" ?

(there's of course also the potential discussion if further ciphers
should be deprecated that are likely weak but not broken - things like
DSS - but I'd keep that discussion separate for now)

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 2 Oct 2014 12:44:06 +0200

Alyssa Rowan <[email-masked]>:

This draft absolutely must not be watered down. We should treat weak
> crypters as broadly equivalent to NULL. That is what this does.
>

NULL is not currently a MUST NOT ... of course, having a cipher suite that
intently and expressly does not encrypt is clearer than having a cipher
suite that offers weak encryption, so it could make sense to have a MUST
NOT for RC4 even as NULL remains around for use cases that need it.

Anyone is entirely free to ignore confidentiality if they don't judge it's
> important in their scenario - but that doesn't mean it's a good idea for
> the internet at large, or that they weren't warned about the risk and chose
> to use it anyway.
>

Translated from prose, I think you're saying SHOULD NOT.

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 2 Oct 2014 12:56:14 +0200

The reasons that this spec talks only about RC4 presumably are that

(1)  only RC4 made it into the TLS 1.2 spec, and
(2)  RC4 currently has much more widespread implementation support (and
practical deployment).

The I-D, however, says "This applies to all TLS versions, and updates
[RFC5246], [RFC4346], and [RFC2246]", so (1) is not a good reason (it would
seem cleaner to say something about the other ciphers too, for the older
protocol versions); and (2) isn't a good reason either (the spec should
stand for itself, not just provide the delta on top of current folklore
knowledge that certain ciphers are out).

So I think a more comprehensive cipher suites MUST NOT / SHOULD NOT
document would be appropriate. (40-bit encryption already is an explicit
MUST NOT for TLS 1.1, but is there any spec that clearly speaks against
using it with TLS 1.0?)

Bodo

---

From: Alyssa Rowan <[email-masked]>
Date: Thu, 02 Oct 2014 12:40:57 +0100

On 2 October 2014 11:44:06 BST, Bodo Moeller <[email-masked]> wrote:
>NULL is not currently a MUST NOT ... of course, having a cipher suite that intently and expressly does not encrypt is clearer than having a cipher suite that offers weak encryption, so it could make sense to have a MUST NOT for RC4 even as NULL remains around for use cases that need it.

Good point. I think that's clearer, although I also think use cases that need NULL are either poorly addressed by TLS or looking at it the wrong way as they own endpoints and can monitor traffic safely there, so keeping NULL around is IMHO more trouble than it's worth in TLS 1.3.

>Translated from prose, I think you're saying SHOULD NOT.

Except that I honestly do not think any "valid" reason exists to use RC4 at this point - which equates to MUST NOT.

Let's go through possible justifications for why I think that, and alternatives:

• Backwards compatibility with rusty legacy implementations? Fine, begrudgingly, choose 3DES, if you *really* must, but you probably SHOULD NOT (implementations that legacy are either out of support so you have bigger problems or can be security patched to use strong ciphersuites instead). It's too weak? (What, and you think RC4's better?) It's affected by BEAST? (Countermeasures against active attacks, disable scripting and Java, and 1,(n-1) splitting.) Bad performance? (There's plenty of 3DES hardware.)

• High performance? AES-GCM (in the presence of hardware support) or ChaCha20-Poly1305. Both faster than RC4 unless you're packing an 8-bit, and quite reasonable even if you are.

• A special deployment where both sides don't care about confidentiality? NULL, then (and repent at leisure when an attacker breaches your trusted network and you've egg all over your face).

Nope, I'm drawing a blank here. Like the 40-bit ciphers, it just doesn't make any sense to me. I can think of no valid reason to use RC4 where something else doesn't work better. Of course I can't force others into that viewpoint, but I can and will say anyone still using it after this RFC is published were warned about the dangers, and of better alternatives, and chose to ignore them to everyone's detriment.

- --
/akr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 02 Oct 2014 14:33:53 +0200

On Thu, 2014-10-02 at 12:40 +0100, Alyssa Rowan wrote:

> [...]
> • High performance? AES-GCM (in the presence of hardware support) or
> ChaCha20-Poly1305. Both faster than RC4 unless you're packing an 8-bit,
> and quite reasonable even if you are.

And that reminds me that Chacha20 does not exist yet. Would it be
reasonable for the WG to adopt the current draft [0] given that Yoav's
draft has been adopted by CFRG?

regards,
Nikos

[0]. http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-02
[1]. https://tools.ietf.org/html/draft-irtf-cfrg-chacha20-poly1305-01

---

From: Yoav Nir <[email-masked]>
Date: Thu, 2 Oct 2014 15:58:01 +0300

Hi, Nikos

I think yes, especially considering that CFRG has just started RGLC on the document.

I think it’s debatable whether we need so many ciphersuites. Considering that TLS 1.3 will be PFS-only and AEAD-only, I’m not sure we need the ciphersuites in section 4.1, and the RSA (without DHE) ciphersuites. The feedback I got in IPsecME was that we didn’t need anything but the AEAD. But that kind of thing can be debated in the working group.

Yoav

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 02 Oct 2014 15:19:52 +0200

On Thu, 2014-10-02 at 15:58 +0300, Yoav Nir wrote:
> I think it’s debatable whether we need so many ciphersuites.
> Considering that TLS 1.3 will be PFS-only and AEAD-only, I’m not sure
> we need the ciphersuites in section 4.1, and the RSA (without DHE)
> ciphersuites. The feedback I got in IPsecME was that we didn’t need
> anything but the AEAD. But that kind of thing can be debated in the
> working group.

Hello Yaov,
 I agree. The non-AEAD ciphersuites are in order to be implementable to
pre-TLS 1.2. Whether they are applicable to TLS 1.3 or not, is outside
the scope of this document.

regards,
Nikos

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 2 Oct 2014 09:22:09 -0500

After thinking about this a bit more, I changed my mind.

I've argued that TLS 1.3 doesn't have to cover every use case supported by TLS 1.2.  On the crypto front, if we (my employer) has to allow RC4 Android 2.2 or old embedded devices (like WWW-TV's), that doesn't change the fact that what these devices are doing isn't good.  I'd prefer to see something like servers should only accept RC4 if it is the best cipher the client supports, but so be it.

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 2 Oct 2014 16:44:37 +0200

One technical issue here is that we keep updating specs that are also
(supposedly) "obsolete". I.e., "If you do that thing that you're not
supposed to do, here's how". It seems to me that having a bit of a gray
area then is unavoidable ... and often you *do* need some latitude in
backwards-compatible cases, assuming you support these to achieve
backwards-compatibility.

(www.microsoft.com, for example, does allow RC4 cipher suites when using
TLS 1.0, which would be incompatible with that MUST NOT, since it expressly
applies to TLS 1.0 too.)

If the spec isn't aligned with reality, that's a bit of a problem. You
shouldn't have to interpret a MUST NOT as a SHOULD NOT.

Maybe the spec should have strict MUST NOT requirements for TLS 1.2, but
make mere recommendations for the legacy protocols? (As mentioned before,
it would be good to also document that various other ciphers like RC2 also
aren't a good idea to use, even which TLS 1.1 which has them in the spec.)

Bodo

---

From: Alyssa Rowan <[email-masked]>
Date: Thu, 02 Oct 2014 18:02:06 +0100

On 2 October 2014 15:44:37 BST, Bodo Moeller <[email-masked]> wrote:
> It seems to me that having a bit of a gray area then is
> unavoidable ... and often you *do* need some latitude in

As I've pointed out, if you're forced into backwards compatibility
with rusty legacy, 3DES is, though crappy, a less crappy choice than RC4.

As Rich points out, just because legacy devices are indeed out there
doesn't mean that they do TLS safely, and doesn't mean we shouldn't
prohibit unsafe practice like using weak ciphers.

> (www.microsoft.com, for example, does allow RC4 cipher suites when 
> using TLS 1.0, which would be incompatible with that MUST NOT,
> since it expressly applies to TLS 1.0 too.)

This draft is a warning to implementers and deployers of TLS that they
MUST change their allowed ciphersuites to completely exclude RC4,
because RC4 isn't safe enough to use in TLS (or really for any purpose
anymore).

Pointing to examples of RC4 still being allowed in the wild only
further demonstrates the need for this draft as-is.

> If the spec isn't aligned with reality, that's a bit of a problem. 
> You shouldn't have to interpret a MUST NOT as a SHOULD NOT.

Reality is, unfortunately, that RC4 should have obsoleted years ago.
That is indeed a bit of a problem - one we now need to fix rapidly.

> Maybe the spec should have strict MUST NOT requirements for TLS
> 1.2, but make mere recommendations for the legacy protocols?

No, not sure I follow your reasoning here: RC4 is no less weak when
used with SSLv3 or TLS 1.0 than with TLS 1.2. Might even be weaker, if
there's a way to trick a server into selecting it (hence the fallback
SCSV draft). I see no reason the prohibition ought not be absolute.

Regarding obsolete ciphers such as RC2 and DES, I don't think the need
to prohibit them is quite as urgent, because people aren't actually
using them in the wild. (Well, not _many_ people, anyway.)

I would indeed support their deprecation - but perhaps in a separate
document, as I'm concerned that any unnecessary delay with this one is
another day that RC4's still actively being used by many, even when
better alternatives are available - which is another day of traffic
Eve can record - and, I fear, break, now or any time later at their
leisure.

The sooner we can proceed, the sooner we can start working to fix that.

- -- 
/akr

---

From: Andrei Popov <[email-masked]>
Date: Thu, 2 Oct 2014 17:54:07 +0000

Thanks for all the comments; I've noticed 3 recurring themes of discussion on this thread so far:

1. Add IANA code points for RC4 cipher suites listed in the Appendix.
I have no objection to this; will do since a lot of people seem to find it helpful.

2. "TLS servers MUST NOT select an RC4 cipher suite" is too strict/constraining/hard to deploy/etc. 
If we removed this MUST NOT, this would not be a prohibiting-rc4 draft, but a best practice recommendation. We have TLS-BCP for recommendations. The idea of prohibiting-rc4 is to completely remove a weak cipher suite.

3. But there are other weak cipher suites: EXPORT, DES, RC2, MD5... 
Totally agree; these need to be removed as well. However, we've been discussing prohibiting-rc4 for over a year now. I think we should let this draft proceed so that we can make some progress. I don't mind authoring a new I-D (or I-Ds) prohibiting EXPORT, DES, RC2, MD5 ciphers.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Alyssa Rowan
Sent: Thursday, October 2, 2014 10:02 AM
To: [email-masked]
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

On 2 October 2014 15:44:37 BST, Bodo Moeller <[email-masked]> wrote:
> It seems to me that having a bit of a gray area then is unavoidable 
> ... and often you *do* need some latitude in backwards-compatible 
> cases, assuming you support these to achieve backwards-compatibility.

As I've pointed out, if you're forced into backwards compatibility with rusty legacy, 3DES is, though crappy, a less crappy choice than RC4.

As Rich points out, just because legacy devices are indeed out there doesn't mean that they do TLS safely, and doesn't mean we shouldn't prohibit unsafe practice like using weak ciphers.

> using TLS 1.0, which would be incompatible with that MUST NOT, since 
> it expressly applies to TLS 1.0 too.)

This draft is a warning to implementers and deployers of TLS that they MUST change their allowed ciphersuites to completely exclude RC4, because RC4 isn't safe enough to use in TLS (or really for any purpose anymore).

Pointing to examples of RC4 still being allowed in the wild only further demonstrates the need for this draft as-is.

> Maybe the spec should have strict MUST NOT requirements for TLS 1.2, 
> but make mere recommendations for the legacy protocols?

No, not sure I follow your reasoning here: RC4 is no less weak when used with SSLv3 or TLS 1.0 than with TLS 1.2. Might even be weaker, if there's a way to trick a server into selecting it (hence the fallback SCSV draft). I see no reason the prohibition ought not be absolute.

Regarding obsolete ciphers such as RC2 and DES, I don't think the need to prohibit them is quite as urgent, because people aren't actually using them in the wild. (Well, not _many_ people, anyway.)

I would indeed support their deprecation - but perhaps in a separate document, as I'm concerned that any unnecessary delay with this one is another day that RC4's still actively being used by many, even when better alternatives are available - which is another day of traffic Eve can record - and, I fear, break, now or any time later at their leisure.

- --
/akr

---

From: [email-masked] (Martin Rex)
Date: Thu, 2 Oct 2014 19:54:46 +0200 (CEST)

> public practical attacks yet) while still allowing RC2(40 bit)/DES

not quite.

TLS cipher suites with three symmetric encryption algorithms
that are described in the TLSv1.1 spec (rfc4346) no longer appear
in TLSv1.2 (rfc5246):   RC2, (single-)DES, and IDEA

For two of these three TLS cipher(suites), a seperate RFC was issued:

  http://tools.ietf.org/html/rfc5469

RC2 may have been left out since it existed only as RC2-40 in SSLv3&TLS.

I prefer the rfc5469 approach by a significant margin over the
science-defying dogmatic, radical extremist approach of the rc4 I-D.
Attacking a single-DES TLS session is *VERY* practical.

Attacking a dozen RC4-encrypted TLS-sessions is infeasible based on
all that we currently know.

-Martin

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 2 Oct 2014 21:13:06 +0200

> No, not sure I follow your reasoning here:

If you're not using TLS 1.2 but an earlier protocol version, then obviously
backwards compatibility is of concern (and there's really no non-crappy
cipher suite available). It seems that you can get by without RC4 when
using TLS 1.2, but obviously sites do still see a need to support RC4 with
older protocol versions.

> document, as I'm concerned that any unnecessary delay with this one

Fair enough.

Bodo

---

From: Alyssa Rowan <[email-masked]>
Date: Thu, 02 Oct 2014 21:13:08 +0100

On 02/10/2014 20:13, Bodo Moeller wrote:
> If you're not using TLS 1.2 but an earlier protocol version, then 
> obviously backwards compatibility is of concern (and there's
> really no non-crappy cipher suite available).

Then reasonable behaviour would be to choose the least weak cipher
available that's still sort of acceptable¹?

RC4 is not sort of acceptable. It's not even the least weak.

> It seems that you can get by without RC4 when using TLS 1.2, but 
> obviously sites do still see a need to support RC4 with older 
> protocol versions.

And this is _exactly_ the behaviour that we're warning needs to stop ASAP.

This isn't some compatibility kludge. This is a weak cipher.

___
[1] And _definitely_ issue the fallback SCSV, in case you're being
tricked into using weak with a new client when you could use strong.

- -- 
/akr

---

From: Yoav Nir <[email-masked]>
Date: Fri, 3 Oct 2014 00:22:52 +0300

> the scope of this document.

HI Nikos

A pre-1.2 implementation of ChaCha20 assumes that there are libraries out there that on the one hand don’t have TLS 1.2, and on the other hand are still actively developed enough that they will implement a new algorithm.

I don’t think that’s the case. If ChaCha20-Poly1305 is going to be implemented in OpenSSL, it’s going to be in 1.0.1 or 1.0.2. I don’t think anyone’s going to add it to 0.9,8, where every recent patch has been a security hotfix.

Similarly, every library I know of that is being maintained already has TLS 1.2.  I don’t feel strongly about it, but I don’t see the use of having new non-AEAD ciphers at this point.

Yoav

---

From: Geoffrey Keating <[email-masked]>
Date: 02 Oct 2014 19:05:50 -0700

Andrei Popov <[email-masked]> writes:

> If we removed this MUST NOT, this would not be a prohibiting-rc4
> draft, but a best practice recommendation. We have TLS-BCP for
> recommendations. The idea of prohibiting-rc4 is to completely remove
> a weak cipher suite.

I support this, and especially the logic behind it.

> Totally agree; these need to be removed as well. However, we've been
> discussing prohibiting-rc4 for over a year now. I think we should
> let this draft proceed so that we can make some progress. I don't
> mind authoring a new I-D (or I-Ds) prohibiting EXPORT, DES, RC2, MD5
> ciphers.

I support this and the logic behind it too.

I would also support creating a new I-D.  TLS 1.1 already says about
the EXPORT ciphersuites:

   TLS 1.1 implementations MUST NOT negotiate
   these [EXPORT] cipher suites in TLS 1.1 mode.  However, for backward
   compatibility they may be offered in the ClientHello for use with TLS
   1.0 or SSLv3-only servers.  TLS 1.1 clients MUST check that the
   server did not choose one of these cipher suites during the
   handshake.  

RFC 5469 says that for DES and IDEA,

   If a TLS library implements these cipher suites, it
   SHOULD NOT enable them by default.  Experience has also shown that
   rarely used code is a source of security and interoperability
   problems, so existing implementations SHOULD consider removing these
   cipher suites.

which is a bit less then the absolute prohibition I'd like, and not
all implementations have actually disabled these ciphers---indeed some
servers in the wild will still negotiate these ciphersuites,
particularly TLS_RSA_WITH_DES_CBC_SHA.

We don't seem to have anything about MD5.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 3 Oct 2014 04:24:18 +0000

On Thu, Oct 02, 2014 at 09:13:08PM +0100, Alyssa Rowan wrote:

> RC4 is not sort of acceptable.

When draft becomes an RFC, it will be widely ignored.  For
interoperability reasons, many applications will sensibly continue
to support RC4 ciphers.  The MUST will have no more effect than a
SHOULD, the latter is all that can be justified at this time.

Mostly all we need is an end to servers preferring RC4 and overriding
the client ciphersuite preference order, and an end to clients
preferring RC4 over stronger options.  Which leaves RC4 in use only
when no stronger options are available.

While we're debating this, Google (for example) is still today
blithely ignoring the RC4 deprecation.  Their outbound SMTP client
prefers RC4 over all other bulk crypto algorithms:

    Oct  2 02:12:30 ... TLS connection established from mail-oi0-f63.google.com[209.85.218.63]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct  2 15:14:52 ... TLS connection established from mail-ie0-f180.google.com[209.85.223.180]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct  2 15:21:49 ... TLS connection established from mail-lb0-f192.google.com[209.85.217.192]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct  2 15:28:26 ... TLS connection established from mail-ig0-f192.google.com[209.85.213.192]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct  2 15:46:09 ... TLS connection established from mail-qc0-f187.google.com[209.85.216.187]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct  2 22:29:06 ... TLS connection established from mail-qc0-f178.google.com[209.85.216.178]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct  3 00:10:20 ... TLS connection established from mail-lb0-f180.google.com[209.85.217.180]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct  3 01:44:04 ... TLS connection established from mail-pa0-f53.google.com[209.85.220.53]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct  3 03:41:55 ... TLS connection established from mail-pd0-f178.google.com[209.85.192.178]: unknown with cipher ECDHE-RSA-RC4-SHA (128/128 bits)

Many others are likely to continue ignoring impractical advice.
A more realistic document is I think likely to see greater adoption.

Recall that most applications are choosing RC4 over stronger options
through explicit operator configuration that no application or
SSL/TLS toolkit can reasonably override.

So in the final analysis, the same degree of operator indifference
will follow from either a MUST or a SHOULD.  Solving the problem
in practice, rather than in theory, means server software and
perhaps hardware upgrades (on systems with no AESNI or similar
support).  Various BCP documents, product tutorials, ... will need
to be updated to discourage preference for the previously popular
RC4.

So documents that mandate disabling RC4 in TLS 1.0 and/or SSL 3.0
are mere security theatre.  The theatre piece that comes to mind
is the Mikado:

    Ko-Ko: When Your Majesty says "Let a thing be done", it's as
    good as done, practically it is done, because Your Majesty's
    will is law. Your Majesty says "Kill a gentleman", and the
    gentleman is to be killed, consequently that gentleman is as
    good as dead, practically he is dead, and if he is dead, why
    not say so?

    The Mikado: I see. (Dramatic Pause) Nothing could possibly be
    more...satisfactory!

It is of course far more reasonable for toolkits to disable RC4
and similarly weak or weaker ciphers with TLS >= 1.2 and negotiate
only lower protocol versions when this leaves no ciphers available.
Presumably with TLS 1.2 both client and server can employ AES-GCM
to avoid both CBC and RC4 issues.

Such a strategy would actually mean that RC4 begins to disappear
sooner, because this could be implemented in toolkits, and could
reasonably trump server policy.

Or we can pretend that operators will care that some RFC says MUST
NOT use RC4.

-- 
	Viktor.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 3 Oct 2014 00:02:02 -0700

> A more realistic document is I think likely to see greater adoption.

Let's be 100% clear here: RC4 is not required for interoperability, as
TLS 1.0, 1.1, and 1.2 all specify other MTI suites for interop.
Disabling RC4 is possible. It needs to be disabled, whether by no
longer offering it or administrator action. The Lucky 13 and BEAST
attacks require either client "features" and are mostly patched
anyway.

> are mere security theatre.  The theatre piece that comes to mind

Aren't these the documents that will precisely "discourage preference
for the previously popular RC4"?

It seems to me that you are arguing for SHOULD so that RC4 can
continue to be used, having conceded it shouldn't be. Every complaint
you make that MUST will end the use of RC4 is exactly a reason to do
it. I don't see how a SHOULD is more likely to lead to action than a
MUST.
> reasonably trump server policy.

Why is this more reasonable than disabling RC4 for all protocol
versions where an alternative cipher exists/is offered and patching
Lucky13+BEAST? (There is also the alternative of enabling the new
extensions: I think we should ask what the path forward for TLS 1.1
is: migration or maintain forever?)

Why can this trump server policy, but preferring AES in all version can't?

> Or we can pretend that operators will care that some RFC says MUST

They will care when the pentester points it out to their boss.

Sincerely,
Watson Ladd

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 03 Oct 2014 11:20:43 +0200

On Fri, 2014-10-03 at 00:22 +0300, Yoav Nir wrote:

> HI Nikos
> 
> A pre-1.2 implementation of ChaCha20 assumes that there are libraries
> out there that on the one hand don’t have TLS 1.2, and on the other
> hand are still actively developed enough that they will implement a new
> algorithm. I don’t think that’s the case. If ChaCha20-Poly1305 is going
> to be implemented in OpenSSL, it’s going to be in 1.0.1 or 1.0.2. I
> don’t think anyone’s going to add it to 0.9,8, where every recent patch
> has been a security hotfix. Similarly, every library I know of that is
> being maintained already has TLS 1.2.  I don’t feel strongly about it,
> but I don’t see the use of having new non-AEAD ciphers at this point.

There have been quite some discussions about that with the TLS WG chairs
as well. I'll provide my point of view here. The need for an alternative
to Poly1305 hash is for redundancy and being conservative when
introducing a new hash (we always had HMAC-SHA1 in addition to
HMAC-MD5). The need for using a compatible with TLS 1.0/1.1 design is
implementation simplicity, and definition simplicity. I elaborate below.

There are several market segments. Some make products that last less
than 2-3 years and after that they are obsolete and unmaintained. That
market segment has the luxury to adopt new technologies quickly and
ignore any issues on a 10 year old mobile phone for example. 

The market segment I work on makes products that are designed to last
for 6+ years (often more than 10) and during that time they are
maintained and get new security features whenever that's possible. While
adding a new stream ciphersuite to TLS 1.0 or 1.1 is trivial, adding
support for TLS 1.2 or AEAD is significant work with many potential
side-effects and regressions, and that is something you don't do on a
production system unless there is a real reason for that.

This provides rationale why I feel that a backwards compatible with TLS
1.0 and TLS 1.1 ciphersuite is needed that can replace RC4. 

The other reason I believe that Chacha20-SHA1 is needed, is redundancy
and backup. Poly1305 is a new MAC algorithm not used anywhere else, and
having a conservative design along it, provides a reasonable fallback.
Why this design uses the TLS stream authenticated encryption? because it
is simpler and safer. The TLS stream authenticated encryption is a tried
and proved construction that combines a MAC and a stream cipher. By
going the AEAD path I'd have to play cryptographer and define a "novel"
Chacha20-SHA1 design, anyway that I'd feel like, send it to IETF to
standardize it as AEAD (possibly pass through CFRG as well), and few
years later when it is obsolete add it to TLS. Then implementers would
have, implement my special design and release. You could argue that I
could specify it to be exactly the same as the stream
authenticated-encryption and shortcut some of that path... Isn't that
what I'm doing? If there was commonly accepted form of AEAD that would
allow to combine a stream cipher and a MAC, that would change things,
but there isn't.

regards,
Nikos

---

From: Joachim Strömbergson <[email-masked]>
Date: Fri, 03 Oct 2014 11:38:04 +0200

Aloha!

Nikos Mavrogiannopoulos wrote:
> There have been quite some discussions about that with the TLS WG
> chairs as well. I'll provide my point of view here. The need for an
> alternative to Poly1305 hash is for redundancy and being conservative
> when introducing a new hash (we always had HMAC-SHA1 in addition to 
> HMAC-MD5). The need for using a compatible with TLS 1.0/1.1 design
> is implementation simplicity, and definition simplicity. I elaborate
> below.

Would it be possible to at least use SHA256 instead of SHA-1? Adding a
new suite that uses SHA-1 in 2015-2016 doesn't look good.

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          [email-masked]
========================================================================

---

From: Yoav Nir <[email-masked]>
Date: Fri, 3 Oct 2014 13:12:17 +0300

On Oct 3, 2014, at 10:02 AM, Watson Ladd <[email-masked]> wrote:

<snip />

> TLS 1.0, 1.1, and 1.2 all specify other MTI suites for interop.

Not required for interoperability with RFCs, but is required for interoperability with real servers:
http://securitypitfalls.wordpress.com/author/hkario/

18% prefer RC4 to all others, while just under 1% support nothing else. This may be because a lot of people configured RC4 only in the wake of the BEAST attack, but regardless: if your browser has no RC4, it can’t browse all  of the Internet.

Yoav

---

From: Hubert Kario <[email-masked]>
Date: Fri, 3 Oct 2014 07:15:14 -0400 (EDT)

----- Original Message -----
> From: "Viktor Dukhovni" <[email-masked]>
> To: [email-masked]
> Sent: Friday, 3 October, 2014 6:24:18 AM

This is also the case for youtube video servers.

Doesn't make it a good idea because it makes it impossible for web clients
to drop RC4...

> SSL/TLS toolkit can reasonably override.

This is not the case.

Only about 1% of servers support only RC4 cipher, 1.5% if you're
using Firefox[1].

On the other hand, over 21% of servers will negotiate a RC4 cipher
in case you're using Firefox (and nearly 18% if you're using
OpenSSL-like supported cipher list).

So by dropping RC4 from your first ClientHello (in case you do use
fallback) may as well cut your RC4 usage by over 20%!

> to be updated to discourage preference for the previously popular

Being able to point PHB to a RFC explicitly disallowing RC4 is a
step in this direction.

> to avoid both CBC and RC4 issues.

 1). AES-128-CBC-SHA1 is faster than AES-GCM if you don't have
     hardware crypto acceleration, consequently RC4 is faster still
 2). People still configure TLS1.1+ capable servers to prefer RC4 
     (over 12% to be exact[1])

We've been asking server operators not to do it for quite some time
already. We need stronger arguments as they simply are not changing
those configurations quickly enough.

 1 - https://securitypitfalls.wordpress.com/2014/09/29/scan-results-for-september-2014/

-- 
Regards,
Hubert Kario

---

From: Hubert Kario <[email-masked]>
Date: Fri, 3 Oct 2014 07:27:37 -0400 (EDT)

----- Original Message -----
> From: "Hubert Kario" <[email-masked]>
> To: [email-masked]
> Sent: Friday, 3 October, 2014 1:15:14 PM

One more thing, it's not really changing for the better:
https://securitypitfalls.wordpress.com/2014/09/23/tls-landscape/
scroll to "Bad recommendations", or see this graph:
https://securitypitfalls.files.wordpress.com/2014/09/rc4-preferral.png

(that's "in general", for Firefox the situation is even worse)

-- 
Regards,
Hubert Kario

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 3 Oct 2014 13:30:43 +0000

> TLS 1.0, 1.1, and 1.2 all specify other MTI suites for interop.

In theory, but in practice it is.

> attacks require either client "features" and are mostly patched

A MUST NOT prefer RC4 is something one can realistically implement.
A MUST NOT offer is something that many will be forced to ignore.
An auditor can just as easily write findings about SHOULD NOT as
MUST NOT.

Documents that don't match operational reality are I think
counter-productive.  They eat away at the credibility of the
standards body publishing the document.

Before RC4 becomes MUST NOT, it needs to first become a low priority
algorithm that is used when nothing better is available.

With Exchange 2003 email servers that are still operating at some
domains the only working ciphersuites are RC4-MD5 and RC4-SHA.
Operators will ignore the IETF and leave RC4 enabled so that mail
can continue to be sent to these domains.

Note also that MTA to MTA mail transactions generally don't carry
fixed sensitive text at a fixed position in the first 256 bytes of
the client or server TLS stream.  This is only an issue with
submission when the client is using "AUTH PLAIN" or "AUTH LOGIN".

I am strongly in favour of educating operators about the weakness
of RC4, provided we give them operationally realistic advice.
I don't see how MUST NOT is such advice.

-- 
	Viktor.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 3 Oct 2014 07:28:53 -0700

> algorithm that is used when nothing better is available.

<snip>
What advice do you want to give them, and how will it end the use of
RC4? The advice given is to not offer RC4 cipher suites on the client
side, and not to pick them on the server side: are we only debating
the third point? Or are you saying that clients should feel free to
offer RC4, and servers should be configured to pick it last?

Sincerely,
Watson Ladd

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 3 Oct 2014 15:01:29 +0000

On Fri, Oct 03, 2014 at 07:28:53AM -0700, Watson Ladd wrote:

> RC4?

Use RC4 at a lower priority than any other non-deprecated 128-bit
or better cipher suite or triple DES (which is rated at 168 bits
by some libraries and 112 bits by others).

There is no reason to prefer single-DES or any 40-bit export cipher
suite over RC4.

> The advice given is to not offer RC4 cipher suites on the client

I am saying that initially (first step on the road to elimination)
both clients and servers SHOULD choose RC4 last when it is not
disabled.  Clients and servers that implement mandatory security
and prioritize security over interoperability SHOULD disable RC4
entirely.  Clients and servers employing opportunistic unauthenticated
encrypted communication SHOULD not disable RC4.  Even RC4 is better
than cleartext or communications failure, as it will only be chosen
when no stronger options are available.

-- 
	Viktor.

---

From: Brian Smith <[email-masked]>
Date: Fri, 3 Oct 2014 09:35:01 -0700

>> but I don’t see the use of having new non-AEAD ciphers at this point.

I agree with this. The ChaCha20-HMAC-SHA-1 cipher suite is not a good
use of resources and should be removed so we can focus on other, more
important, improvements.

> production system unless there is a real reason for that.

There are real reasons to add support for TLS 1.2 to stable products
like RHEL (in particular). For example, versions less than 1.2 rely on
the collision resistance of MD5 and SHA1, which really a bad idea.
Further, nobody would be able to deploy HTTP/2 effectively (i.e. works
with most browsers) without TLS 1.2, unless their products avoid the
system crypto stack, which is counter to the purpose of having a
system crypto stack in the first place. Consequently, I think it makes
a lot more sense to spend time to figure out how to spread TLS 1.2 to
these more conservative products and deployments, than it does to
spend time figuring out how to avoid doing so.

Further, why would any user that is too change-averse to deploy TLS
1.2 want to deploy ChaCha20 cipher suites?

> The other reason I believe that ChaCha20-SHA1 is needed, is redundancy

We already have the AES-based cipher suites for fallback.

> years later when it is obsolete add it to TLS.

You had to do the same thing for the stream construction. See
https://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-03#section-5
where you redefine the stream construction.

> Then implementers would
> have, implement my special design and release.

Who is planning to implement ChaCha20-SHA1, regardless of how it is
specified? I expect very few people to do so.

Also, some newer implementations of TLS may not even implement the
stream mode construction at all, since currently it is used only for
RC4. This makes it even less likely that implementations will support
the HMAC-SHA1 version.

Cheers,
Brian

---

From: Watson Ladd <[email-masked]>
Date: Fri, 3 Oct 2014 09:37:48 -0700

> implementation simplicity, and definition simplicity. I elaborate below.

Right conclusion: wrong reasons. Carter-Wegman MACs are
unconditionally secure, but the code changes are minimized by reusing
a MAC.

Unfortunately the draft bobbles nonce handling: it's not clear to me
how the nonce is generated in TLS 1.1 and TLS 1.0.
> The market segment I work on makes products that are designed to l

There is: encrypt then MAC, using two different keys and the same
nonce. This has been known for at least 20 years.

---

From: James Cloos <[email-masked]>
Date: Fri, 03 Oct 2014 17:37:31 -0400

>>>>> "HK" == Hubert Kario <[email-masked]> writes:

HK> Only about 1% of servers support only RC4 cipher, 1.5% if you're
HK> using Firefox[1].

When this first came up I test a few of them.  Some of the sites I
tested had some sort of load balancing box listening on the main uri
which redirected to the real servers.  In each of the cases of that
sort where the redirecting box only supported rc4, the destinations
all supported a reasonably modern set of ciphers.

So the problem isn't just updating typical web servers, but also dealing
with what are likely low-spec closed-source fronts.  It may be impossible
for some of the rc4-only sites to fix that w/o replacing (probably over-
priced) hardware.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Paul Lambert <[email-masked]>
Date: Fri, 3 Oct 2014 19:46:29 -0700

]Before RC4 becomes MUST NOT, it needs to first become a low priority
]algorithm that is used when nothing better is available.

We are over thinking the presumed interoperability concerns.

There are no RFC police to enforce SHOULD versus MUST. There
will not be a red-flag day when RC4 is apparently turned off 
with a "MUST NOT" in a document from this group. 

A 'SHOULD NOT' recommendation is readily ignored. There is no
clear guidance, only a suggestion.  Guidance on industry practice
for such a feature is very important to help determine diligence
of an implementation to follow recommended industry practice.

A 'MUST NOT', could be ignored, but installations that are audited
for compliance to "recommended industry practice" would be dinged.
This introduces potential liability and financial risks that would
encourage the removal of RC4.

'SHOULD NOT' carries no incentive for change.
'MUST NOT' provides clear guidance and incentive that will still 
take many years to be adopted fully.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 4 Oct 2014 03:35:47 +0000

On Fri, Oct 03, 2014 at 07:46:29PM -0700, Paul Lambert wrote:

> We are overthinking the presumed interoperability concerns.

Well, I for one am not.   Disabling RC4 does more harm than good
with opportunistic TLS.  A far better approach in that case is to
de-priorioritize it.  Giving some check-list enforcing clue-less
auditor the ammunition to harass users into counter-productive
"security" measures is not my idea of progress.

> of an implementation to follow recommended industry practice.

And yet this is the strongest recommendation appropriate at this
time.

> encourage the removal of RC4.

Not all applications face the same risks, and removing RC4 will some
applications *less* secure at least some of the time.

> 'SHOULD NOT' carries no incentive for change.

This is not the case.  Both are good reason to take action.
SHOULD NOT leaves room to consider when and how to respond.

> take many years to be adopted fully.

MUST NOT is overly broad and premature, we're moving from RC4 is
best to RC4 is worst too quickly, leaving too little time to reduce
the operational impact while use of RC4 is allowed to die down as
auditors nag people about the "SHOULD NOT", various tutorials and
guidelines are updated, articles are written, ...

I think I've said as much as I must and should in this thread.
Future silence will not indicate agreement with MUST NOT, rather
only that there is little new to say.

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 04 Oct 2014 19:08:03 +0100

Hi Viktor,

(No hats and without taking a position on the draft itself yet...)

On 04/10/14 04:35, Viktor Dukhovni wrote:
> with opportunistic TLS.

Not sure I agree with that specific point. Disabling RC4 could be
a configuration or code change, depending.

If a code change is needed to disable RC4 then its going to be fine
to use a better alg. I don't see there's a real case where there's
no better alg to code up than RC4.

If disabling RC4 is a config change, then in almost all cases the
result should be a better alg being selected. There could I guess
be cases where there's nothing better to configure, but frankly, I
doubt that that's really a significant set of TLS installations.
(Note that's not to say that those currently using RC4 are not
significant - I'd say a lot of those could in principle change but
just haven't yet.)

And if anyone is going to disable RC4 and as a result end up with
cleartext, then we should just get them a new foot-gun:-)

So I don't think that the opportunistic security design really helps
to decide SHOULD NOT vs MUST NOT for this draft.

S.

---

From: "Carl S. Gutekunst" <[email-masked]>
Date: Sat, 04 Oct 2014 11:26:58 -0700

> OpenSSL-like supported cipher list).

Note that in the SMTP world, use of RC4 (and a bias towards RC4) is more 
prevalent than on web servers. This is in large measure because 
Microsoft Exchange Server 2003 shipped with only RC4 and 3DES, and the 
3DES implementation crashed somewhere around the MAIL FROM dialog. I 
still regularly run into these old, unpatched servers. I tell them to 
install AES support, but they usually ignore me, abandon my product, and 
switch to one that "works" -- that is, it uses TLS v1 and RC4.

<csg>

---

From: Watson Ladd <[email-masked]>
Date: Sun, 5 Oct 2014 16:54:00 -0700

> for some of the rc4-only sites to fix that w/o replacing (probably over-

Then that's what they are going to have to do at some point. SHOULD
pushes that point off with no reason.

---

From: James Cloos <[email-masked]>
Date: Mon, 06 Oct 2014 09:31:12 -0400

>>>>> "WL" == Watson Ladd <[email-masked]> writes:

>> for some of the rc4-only sites to fix that w/o replacing (probably over-

WL> Then that's what they are going to have to do at some point. SHOULD
WL> pushes that point off with no reason.

TO be clear, I wasn't arguing against retiring rc4, just noting that
sites exist which are unlikely to do so in the short to medium term.

-JimC

---

From: Andrei Popov <[email-masked]>
Date: Mon, 6 Oct 2014 17:13:42 +0000

> TO be clear, I wasn't arguing against retiring rc4, just noting that sites exist which are unlikely to do so in the short to medium term.
Absolutely, but I think most new RFCs take a while to be implemented and deployed. RC4 is not going to become any more secure in the short, medium, or long term, so I believe prohibiting-RC4 will remain relevant for as long as TLS versions <1.3 are in use.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of James Cloos
Sent: Monday, October 6, 2014 6:31 AM
To: Watson Ladd
Cc: [email-masked]
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

>> So the problem isn't just updating typical web servers, but also 
>> dealing with what are likely low-spec closed-source fronts.  It may 
>> be impossible for some of the rc4-only sites to fix that w/o 
>> replacing (probably over-
>> priced) hardware.

TO be clear, I wasn't arguing against retiring rc4, just noting that sites exist which are unlikely to do so in the short to medium term.

-JimC

---

From: [email-masked] (Martin Rex)
Date: Mon, 6 Oct 2014 21:58:44 +0200 (CEST)

> fallback) may as well cut your RC4 usage by over 20%!

We're talking past each other here.

I'm perfectly OK with the MUST NOT for the __client__ (!!), and
I will not mind the slightest if (Browser or other) TLS clients that
implement the awkward application-level reconnect fallback logic
for TLS handshake failures start "punishing" the remaining RC4-only
servers with reconnect fallbacks.

My issue is with the IMHO bogus "MUST NOT" for servers.
Servers have no control over the client behaviour, and the current
proposal calls for an unconditional hard failure (equals to
"come back in clear text") rather than interoperating with an
RC4-based TLS cipher suites with installed base clients.

Based on what we currently know about the weaknesses of RC4,
unconditionally turning down clients will be ridiculously stupid
in most situations, because for the vast number of scenarios,
the weakness of the TLS RC4 cipher suites is not a threat.

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Mon, 6 Oct 2014 23:12:28 +0300

> the weakness of the TLS RC4 cipher suites is not a threat.

Hi, Martin.

Both your implementation and mine have to deal with customers that run 4 or 5 year old software, and refuse to patch their systems. We know this is true, because TLS has a padding extension only because customers refuse to patch their systems.

So if the version that I am working on now is going to come out in 2015, some customers are going to run it in 2020. It should not include things that are likely to be ridiculous in 2020. So avoiding RC4 now is good. Avoiding SHA-1 in signatures is another good idea. Google can patch everyone’s Chrome in days. We are not so lucky.

So I think it should be MUST NOT for RC4. If some things can’t yet afford to comply with the new RFC, so be it. They’ll get there eventually.

Yoav

---

From: Hubert Kario <[email-masked]>
Date: Mon, 6 Oct 2014 16:17:22 -0400 (EDT)

----- Original Message -----
> From: "Martin Rex" <[email-masked]>
> To: "Hubert Kario" <[email-masked]>
> Cc: [email-masked]
> Sent: Monday, 6 October, 2014 9:58:44 PM

that doesn't increase security against targeted attacks, which are
basically the only ones against which we need protection
 
> RC4-based TLS cipher suites with installed base clients.

thing is that only very specific clients do advertise only RC4,
far less than there are RC4 only servers. Cloudflare saw on the
order of 0.000002% of connections end up with RC4:
http://blog.cloudflare.com/the-web-is-world-wide-or-who-still-needs-rc4/
All from long obsolete clients.

Previously they saw on the order of 0.0009%:
http://blog.cloudflare.com/killing-rc4-the-long-goodbye/

-- 
Regards,
Hubert Kario

---

From: [email-masked] (Martin Rex)
Date: Mon, 6 Oct 2014 22:24:11 +0200 (CEST)

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

I'm not sure how representative that cloudflare statistic is.

But if this is anywhere near the real numbers, that the current
"MUST NOT" for server would be clear fear-mongering rather than
providing the target audience a sensible information about the
trade-off and realistic perspective on the insignificance of
the perceived threat.

-Martin

---

From: Ralph Holz <[email-masked]>
Date: Wed, 08 Oct 2014 23:27:38 +0200

Hi,

> 2. "TLS servers MUST NOT select an RC4 cipher suite" is too
> strict/constraining/hard to deploy/etc. If we removed this MUST NOT,
> this would not be a prohibiting-rc4 draft, but a best practice
> recommendation. We have TLS-BCP for recommendations. The idea of
> prohibiting-rc4 is to completely remove a weak cipher suite.

The BCP MUST NOTs RC4.

It also MUST NOTs the NULL cipher, but says clearly that some scenarios
require it, and these are not in scope.

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18010
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

---

From: Ronald del Rosario <[email-masked]>
Date: Thu, 9 Oct 2014 17:06:00 +0000

"I'm not sure how representative that cloudflare statistic is.

-Martin”

+1

I live in a browser-integration world (CRM, Softphone clients, etc.) and disabling support for RC4 will be a burden since we still have a big percentage of customers using WindowsXP/IE6 (Obsolete clients) due to legacy custom integrations they are running.

I feel that making RC4 a "MUST NOT” and ending up as an IETF Standard is too much fear-mongering.

Best,

Ron F. del Rosario
Information Security Officer

Five9, Inc.
Cloud Contact Center Software
4000 Executive Pkwy, Ste 400 San Ramon, CA 94583
www.Five9.com<http://www.five9.com/>

From: Martin Rex <[email-masked]<mailto:[email-masked]>>
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 6, 2014 at 1:24 PM
To: Hubert Kario <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

Hubert Kario wrote:

-Martin

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

________________________________

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential information of Five9 and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Five9 and/or its affiliated entities.

---

From: Chris Newman <[email-masked]>
Date: Wed, 15 Oct 2014 16:40:24 -0700

I agree with this:

--On October 4, 2014 3:35:47 +0000 Viktor Dukhovni <[email-masked]>
wrote:
> ...

As an implementer of a product with TLS/SSL support, I will ignore the three
MUST/MUST NOT statements in this draft. As long as the SSL/TLS library I use
supports RC4, I'm going to support RC4. And I'll be reluctant to upgrade to an
SSL/TLS library that doesn't support RC4 for fear of breaking customer
interoperability and forcing opportunistic connections to clear text.

I believe the goal should be to replace RC4 usage in the real world with use of
stronger cipher suites. I do not believe the current draft will advance that
goal. Statements similar to the single-DES advice in RFC 5469 may advance that
goal. Here are other statements that may advance that goal:

* SSL/TLS software MUST prefer stronger cipher suites (presently AES and 3DES)
over RC4.

* SSL/TLS libraries MUST disable RC4 cipher suites by default. An application
MUST make an explicit SSL/TLS library API call to enable RC4 cipher suites if
they are needed for backwards compatibility.

* SSL/TLS software MUST disable RC4 cipher suites when TLS 1.1 or 1.2 are
negotiated and SHOULD disable RC4 cipher suites by default when earlier
versions are negotiated. For an opportunistic security transmission, such as
for SMTP relay (RFC 3207), RC4 MAY be used as a last resort for
interoperability prior to fallback to transmission without SSL/TLS.

* User agents that employ SSL/TLS for security MUST NOT indicate the connection
is secure when RC4 is used. For example, a web browser that displayed a lock
icon when an RC4 cipher suite was used would fail to comply with this
requirement.

		- Chris

---

From: Joseph Salowey <[email-masked]>
Date: Sat, 18 Oct 2014 11:32:50 -0700

The main concern that I have with this approach is that attacks against RC4
will only get better and while the attacks may be currently impractical
against HTTP cookies perhaps there are other usages where the problem may
be greater.

Pragmatically, implementers will do what is necessary to interoperate, so I
think something along the lines of what Chris recommends below may be the
best way forward.    I'm a bit reluctant to bring opportunistic security
into the discussion at this point, but I think the rest is OK.

Do folks think this is an acceptable way forward?

Thanks,

Joe

On Wed, Oct 15, 2014 at 4:40 PM, Chris Newman <[email-masked]>
wrote:

> I agree with this:
>
> --On October 4, 2014 3:35:47 +0000 Viktor Dukhovni <[email-masked]
> >
> wrote:

---

From: Andrei Popov <[email-masked]>
Date: Tue, 21 Oct 2014 00:52:10 +0000

The intent of draft-ietf-tls-prohibiting-rc4 is exactly what the title says: to prohibit the use of RC4-based cipher suites in the TLS protocol. In practice, prohibiting RC4 means that the TLS clients MUST NOT advertise RC4 support, and the TLS servers MUST NOT select an RC4 cipher suite. Both parts are crucially important to achieve the purpose of the I-D.

If the TLS WG cannot reach rough consensus that RC4 cipher suites need to be prohibited, then I think the way forward is for the WG to reject draft-ietf-tls-prohibiting-rc4, and wait for the RC4 attacks to improve even further.

In the meantime, alternative I-Ds can of course be authored to discourage the use of RC4, although the TLS BCP already does so.

Thanks,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Joseph Salowey
Sent: Saturday, October 18, 2014 11:33 AM
To: Chris Newman
Cc: [email-masked]
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

The main concern that I have with this approach is that attacks against RC4 will only get better and while the attacks may be currently impractical against HTTP cookies perhaps there are other usages where the problem may be greater.

Pragmatically, implementers will do what is necessary to interoperate, so I think something along the lines of what Chris recommends below may be the best way forward.    I'm a bit reluctant to bring opportunistic security into the discussion at this point, but I think the rest is OK.

Thanks,

Joe

On Wed, Oct 15, 2014 at 4:40 PM, Chris Newman <[email-masked]<mailto:[email-masked]>> wrote:
I agree with this:

                - Chris

---

From: Watson Ladd <[email-masked]>
Date: Mon, 20 Oct 2014 17:59:47 -0700

On Mon, Oct 20, 2014 at 5:52 PM, Andrei Popov
<[email-masked]> wrote:
> The intent of draft-ietf-tls-prohibiting-rc4 is exactly what the title says:
> to prohibit the use of RC4-based cipher suites in the TLS protocol. In
> practice, prohibiting RC4 means that the TLS clients MUST NOT advertise RC4
> support, and the TLS servers MUST NOT select an RC4 cipher suite. Both parts
> are crucially important to achieve the purpose of the I-D.
>
>
>
> If the TLS WG cannot reach rough consensus that RC4 cipher suites need to be
> prohibited, then I think the way forward is for the WG to reject
> draft-ietf-tls-prohibiting-rc4, and wait for the RC4 attacks to improve even
> further.

We've reached consensus RC4 is not a good idea. But, like Saint
Augustine, "grant me strong ciphers, but not today!".
That said, Chris's approach helps get us some of the way there.

Sincerely,
Watson Ladd
>
>
>
> In the meantime, alternative I-Ds can of course be authored to discourage
> the use of RC4, although the TLS BCP already does so.
>
>
>
> Thanks,
>
>
>
> Andrei
>
>
>
> against HTTP cookies perhaps there are other usages where the problem may be
> greater.
>
>
>

---

From: Andrei Popov <[email-masked]>
Date: Tue, 21 Oct 2014 05:13:33 +0000

Chris's language reads weaker than the TLS BCP, but if folks want to pursue this, that's up to the WG. My point is that this should be a different I-D, because it does not amount to "prohibiting RC4".

Cheers,

Andrei
________________________________________
From: Watson Ladd <[email-masked]>
Sent: Monday, October 20, 2014 5:59 PM
To: Andrei Popov
Cc: Joseph Salowey; Chris Newman; [email-masked]
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

Sincerely,
Watson Ladd

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 21 Oct 2014 01:58:23 -0400

> Chris's language reads weaker than the TLS BCP, but if folks want to pursue
> this, that's up to the WG. My point is that this should be a different I-D,
> because it does not amount to "prohibiting RC4".

+1

Kill RC4 or put our face on it and face the public embarrassment.

It is clearly a best practice to not use RC4. Sure, some clients and servers have no choice and have to do so. So what?  The Internet is full of systems that do not follow best practices. That should not change what the "best" practice is.

---

From: Alyssa Rowan <[email-masked]>
Date: Tue, 21 Oct 2014 09:10:46 +0100

>Kill RC4 or put our face on it and face the public embarrassment.

Strong +1. I couldn't be stronger here.

I think we have rough consensus to publish this draft as-is right now, despite a couple of vocal but wrong-headed objections. I don't think further discussion makes RC4 any more, or less, weak, but delay keeps people using it for longer and that is bad.

If this WG cannot even achieve rough consensus about turning off a weak 20-year-old piece-of-crap cipher everyone knows is bad and which many fear will soon be (according to some sources has already been) broken catastrophically and irretrievably, then we have a much deeper problem and this WG is going to look utterly ineffectual and useless - which would mean taking our security, and pushing it somewhere else which can deal with it.

If you're waiting for a catastrophic break to be published to disable a cipher when it's already a decade overdue and you've been warned it's weak, then sorry but you're a complete idiot, attackers have saved all your juicy ciphertexts for the promised day, and will just sit there looking back at your (and your customers') precious data.

Anyone is free to ignore an RFC: just remember Chris, we warned you RC4 was weak; we told you that you MUST NOT use it in the clearest possible language. If you want to ignore that, you're facing the music when a break is published. Keeping RC4 enabled is the kind of thing you should, and will, fail audits for.

Don't make me get the whips out! ;-)

- --
/akr

---

From: Yoav Nir <[email-masked]>
Date: Tue, 21 Oct 2014 13:57:13 +0300

+1

Outright prohibit RC4. If someone still supports RC4, then they’re not compliant with the RFC, nothing more, nothing less.

And if some auditors take it upon themselves to threaten administrators into removing support for RC4, then for once they’re doing something we can all get behind.

Yoav

> On Oct 21, 2014, at 11:10 AM, Alyssa Rowan <[email-masked]> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> -----BEGIN PGP SIGNATURE-----
> Version: APG v1.1.1
> 
> iQI3BAEBCgAhBQJURhUGGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
> jtkWi2t6088P/imVPNrVpDrcyG0Gsl/5sMCqasrzSfDEG8ZJZNUNGQ3msCA1SzYr
> XEx4FVHVX2/0fwrDftIU/N+1ECiV+l6PQf7Xoeh6XBr0P8gxMocb49J2rlZGhV9c
> aZPfz40wktglMJYNlXoKu2GsoUTOaBY+DUiOygpB0nerix9k06FXcuu26y3eGyB+
> bMlL2oxNvrpYJtbBNrPaRAKr1xee8AwaQzWkWoqeqjBJjwCKGp98SUS96jpXddp3
> P55CDs15LsMP2dHJtkM6xS1OZWAHEZwG+3BSGJOgrkMD1hMstwNAFtJxTmOc/BRs
> uFbUpYISxp1s+6ZZYH94e8Nzcr0mF6AYS3AjAXTZDGzl62LQajafxLVA13Bokoia
> KHvvxylIvDNqSYu4nysJrjOX8rnrDk1m7dPZBG1Yj++4zJZ5KbxBUhzjYooX0yzp
> IWIeveDOswD4n8oTKeRN3CnwYc25GLHhyg+jGrs5ullFNKwTh12G726XTd8FeGOO
> AdMO0T23qhj2JpzOT2v8fd2+03FEWhkc24w/2BrdtfwZWOwN1CG9kaIMnkUzOefd
> 50Myy1Iws33P6tOm4X/v7vvtDLQo+aZbfHebkU4289j4D1e+e50QfWR+AYqhOOI7
> dKkVMIiZALHTnlLFn9dMO2UIjlYffaugjQNBvppcqWviarYW4zi5cVNi
> =t57m
> -----END PGP SIGNATURE-----
>