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

Stephen Farrell <> Sat, 04 October 2014 18:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A7AA81A0126 for <>; Sat, 4 Oct 2014 11:08:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h-PHLf3rTYdR for <>; Sat, 4 Oct 2014 11:08:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 87A241A0127 for <>; Sat, 4 Oct 2014 11:08:06 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A326BE59 for <>; Sat, 4 Oct 2014 19:08:05 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7oVWRMnyWEqO for <>; Sat, 4 Oct 2014 19:08:04 +0100 (IST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id E82CEBE20 for <>; Sat, 4 Oct 2014 19:08:03 +0100 (IST)
Message-ID: <>
Date: Sat, 04 Oct 2014 19:08:03 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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: Sat, 04 Oct 2014 18:08:31 -0000

Hi Viktor,

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

On 04/10/14 04:35, Viktor Dukhovni wrote:
> Well, I for one am not.   Disabling RC4 does more harm than good
> 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.