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

Viktor Dukhovni <> Wed, 22 October 2014 17:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DBD051ACEB3 for <>; Wed, 22 Oct 2014 10:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SZ4ZSswmu2Xs for <>; Wed, 22 Oct 2014 10:52:41 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5583D1ACE9E for <>; Wed, 22 Oct 2014 10:52:41 -0700 (PDT)
Received: by (Postfix, from userid 1034) id 483872AB109; Wed, 22 Oct 2014 17:52:39 +0000 (UTC)
Date: Wed, 22 Oct 2014 17:52:39 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
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, 22 Oct 2014 17:52:51 -0000

On Wed, Oct 22, 2014 at 10:28:54AM -0700, Ryan Carboni wrote:

> This is why SHA-256 will never have a malicious collision, and why RC4 will
> never be broken.

Well, never is a long time, and it is already somewhat broken, in that
the bias in at least firt 256 bytes of output makes fixed plaintexts
transmitted repeatedly under varying keys vulnerable to recovery.

While I would prefer to see RC4 phased out more gradually, I do
not think we can claim that it has not been broken.

So I think that it would be nice if there was some wiggle-room for
opportunistic TLS.  As weak as RC4 might be, it is stronger than
cleartext.  And the published bias attacks don't apply to MTA to
MTA SMTP.  There is no (pairwise) fixed sensitive plaintext at a
fixed offset in every MTA to MTA email transaction.

I have no objections to banning RC4 for "strict" TLS use-cases.