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

Alyssa Rowan <> Fri, 08 August 2014 13:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D36551B29B9 for <>; Fri, 8 Aug 2014 06:49:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vjh6_gyZDlKx for <>; Fri, 8 Aug 2014 06:49:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6E0BB1B29E8 for <>; Fri, 8 Aug 2014 06:49:45 -0700 (PDT)
User-Agent: K-9 Mail for Android
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
From: Alyssa Rowan <>
Date: Fri, 08 Aug 2014 14:49:39 +0100
Message-ID: <>
Subject: Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00
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: Fri, 08 Aug 2014 13:49:48 -0000

Hash: SHA512

On 8 August 2014 14:36:28 BST, wrote:

>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,
>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
>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).

(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.

- --
Version: APG v1.1.1