Re: [TLS] draft-ietf-tls-prohibiting-rc4-01 opportunistic security

Pete Resnick <> Thu, 08 January 2015 05:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5DEB71A8852; Wed, 7 Jan 2015 21:34:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Cilcc4cVtsSj; Wed, 7 Jan 2015 21:34:16 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E9CB71A0E10; Wed, 7 Jan 2015 21:34:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1420695255; x=1452231255; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=n+w5uBAT/mBxU9+Skgu0BsGfKQP9HIwCLZjxB1Rahio=; b=lFuM2+tISdcmpxsmL30cBkVNIs4gM0BlJkfpwyKEsMBo/UZFeJSZvh9R 2syDjJMhg55LLerU7Wu8/mB4C0Uyz+A/JBf0X4pNgzktSjjTZLMmFech7 NCY1wlqNlbJxjjsMlsSuK/hn2Kx1Rhy+ktr6CIPNXzUfCS6AFbt9qSb1R Q=;
X-IronPort-AV: E=McAfee;i="5600,1067,7674"; a="97104533"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jan 2015 21:34:14 -0800
X-IronPort-AV: E=Sophos;i="5.07,719,1413270000"; d="scan'208";a="825636767"
Received: from ([]) by with ESMTP/TLS/RC4-SHA; 07 Jan 2015 21:34:14 -0800
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 7 Jan 2015 21:34:13 -0800
Message-ID: <>
Date: Wed, 07 Jan 2015 23:34:11 -0600
From: Pete Resnick <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv: Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Dave Garrett <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
X-ClientProxiedBy: ( To (
Cc: " (" <>,, The IESG <>
Subject: Re: [TLS] draft-ietf-tls-prohibiting-rc4-01 opportunistic security
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: Thu, 08 Jan 2015 05:34:18 -0000

[Cc'ing the IESG, since this document is currently being discussed there]

FYI, just so this doesn't generate a long thread on TLS for no reason:

I am reading over the October WG list discussion on the draft where it 
appears this issue did come up, and my reaction so far is that I may 
simply be in the rough part of the rough consensus that existed on the 
list. That is, I think there is an issue here (i.e., the potential for a 
future OS implementation that, while being able to do better than RC4, 
may want to talk to something that can only either RC4 or clear text), 
but it looks like the WG did consider this objection and reasonably 
concluded that the current text is sufficient to cover the case. I do 
think it's a bit bogus for a document to say "implementations MUST NOT 
do X" when we know full-well that there is at least one good reason to 
ignore that requirement, but that's not enough for me to hold up the 
document. So unless I spot some point in the discussion of this topic 
that I think the WG really muffed, I'm almost certain to ballot No 
Objection before the IESG telechat tomorrow.


On 1/7/15 11:20 PM, Dave Garrett wrote:
> A reply to Pete Resnick's ballot comment for draft-ietf-tls-prohibiting-rc4-01:
> Under what opportunistic security implementation would something better than RC4
> not be supported by both endpoints? (I'm curious is one exists at all)
> Considering it permissible risks encouraging the usage of RC4 for opportunistic
> security, rather than more secure ciphers.
> If it is no longer fit for any purpose then the goal should be to kill it off
> entirely. Diluting the requirement risks compromising that goal. I'm not
> inclined to believe this is a "better than nothing" scenario unless there exists
> data on an existing RC4 OS system with a particularly large number of users that
> won't be upgraded. Though, in that case, they may just not honor this RFC.
> A simple requirement is best. I'm just sending this in the hope that this very
> good progress isn't made unnecessarily more complicated at the last second.
> Dave

Pete Resnick<>
Qualcomm Technologies, Inc. - +1 (858)651-4478