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

Chris Newman <> Wed, 15 October 2014 23:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DB9531ACE79 for <>; Wed, 15 Oct 2014 16:40:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RGZ2_oNna1vU for <>; Wed, 15 Oct 2014 16:40:28 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 123C11ACE0E for <>; Wed, 15 Oct 2014 16:40:28 -0700 (PDT)
Received: from ( []) by (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s9FNeQbq005074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <>; Wed, 15 Oct 2014 23:40:27 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4) with ESMTP id s9FNeQl3021464 for <>; Wed, 15 Oct 2014 23:40:26 GMT
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; CHARSET=US-ASCII
Received: from [] ( []) by (Oracle Communications Messaging Server 64bit (built May 5 2014)) with ESMTPSA id <> for; Wed, 15 Oct 2014 16:40:26 -0700 (PDT)
Date: Wed, 15 Oct 2014 16:40:24 -0700
From: Chris Newman <>
Message-id: <>
In-reply-to: <> <> <>
References: <>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
X-Source-IP: []
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: Wed, 15 Oct 2014 23:40:30 -0000

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