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

Andrei Popov <> Tue, 21 October 2014 00:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4006B1ACF65 for <>; Mon, 20 Oct 2014 17:52:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EHBVU_Hv5gM1 for <>; Mon, 20 Oct 2014 17:52:12 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 164701ACF0A for <>; Mon, 20 Oct 2014 17:52:12 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1054.13; Tue, 21 Oct 2014 00:52:10 +0000
Received: from ([]) by ([]) with mapi id 15.00.1054.004; Tue, 21 Oct 2014 00:52:10 +0000
From: Andrei Popov <>
To: Joseph Salowey <>, Chris Newman <>
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
Thread-Index: AQHP3c1Ub4FUPtdXakGIHJMHMTXmG5wx5z5wgARg/gCAA4jTEA==
Date: Tue, 21 Oct 2014 00:52:10 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2001:4898:80e8:ed31::2]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB419;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 0371762FE7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(55674003)(199003)(377454003)(164054003)(189002)(24454002)(76576001)(105586002)(31966008)(33646002)(95666004)(120916001)(74316001)(99286002)(107046002)(19617315012)(99396003)(106116001)(76482002)(15975445006)(86362001)(106356001)(19300405004)(19609705001)(85852003)(19580395003)(19580405001)(54356999)(50986999)(76176999)(87936001)(2656002)(92566001)(85306004)(108616004)(4396001)(230783001)(40100003)(122556002)(19625215002)(93886004)(16236675004)(46102003)(15202345003)(101416001)(80022003)(21056001)(20776003)(24736002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB419;; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_cce9c5f96fe944d5b4f6007d1c4a1bb2BL2PR03MB419namprd03pro_"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
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: Tue, 21 Oct 2014 00:52:15 -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.



From: TLS [] On Behalf Of Joseph Salowey
Sent: Saturday, October 18, 2014 11:33 AM
To: Chris Newman
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.

Do folks think this is an acceptable way forward?



On Wed, Oct 15, 2014 at 4:40 PM, Chris Newman <<>> wrote:
I agree with this:

--On October 4, 2014 3:35:47 +0000 Viktor Dukhovni <<>>
> 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.
> ...
> Not all applications face the same risks, and removing RC4 will some
> applications *less* secure at least some of the time.

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

                - Chris

TLS mailing list<>