[TLS] draft-ietf-tls-prohibiting-rc4-01 opportunistic security
Dave Garrett <davemgarrett@gmail.com> Thu, 08 January 2015 05:20 UTC
Return-Path: <davemgarrett@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7E01A885A for <tls@ietfa.amsl.com>; Wed, 7 Jan 2015 21:20:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJhfE4IaBAUf for <tls@ietfa.amsl.com>; Wed, 7 Jan 2015 21:20:22 -0800 (PST)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A7D91A8854 for <tls@ietf.org>; Wed, 7 Jan 2015 21:20:22 -0800 (PST)
Received: by mail-qg0-f53.google.com with SMTP id l89so778188qgf.12 for <tls@ietf.org>; Wed, 07 Jan 2015 21:20:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:mime-version:content-type :content-transfer-encoding:message-id; bh=1rd2XG4RVPsDcoeGSGCtm2yNPiFsZve2nqiMSp0SDyY=; b=eyFlaDUf1CCQCVDuSvc328FsBjepx+FCMo8G+kFGepe3eL8LwwL5CUPzLMtC001yxi nk9z5bvc+oKNgk5xu69aKOtGm3YYNvigmQpA9oLpGQpjbRsMyW0WGyIOpnEyqOUUEH1p iS4CSjDeaf8LXHr0kRoIOVngc+/PHcFKiU9+RGprhLB7QruoLKNdyc94/q48jxU0JDgg hvRV4YX66M6yiDSg5nh1t/dVZxXSfSa88xgapIY6nQf4YZN+zyqo/+SNHZO9c7702nTk 67HQTTgaG8y7HNp1jd73MWMQd73Tv2isHdgZmQo3urnwzAShRf7zFXWX7sUDb92yM+t8 K49A==
X-Received: by 10.229.126.129 with SMTP id c1mr11965957qcs.12.1420694421841; Wed, 07 Jan 2015 21:20:21 -0800 (PST)
Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id 91sm3195630qgf.1.2015.01.07.21.20.21 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 07 Jan 2015 21:20:21 -0800 (PST)
From: Dave Garrett <davemgarrett@gmail.com>
To: presnick@qti.qualcomm.com
Date: Thu, 08 Jan 2015 00:20:19 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-70-generic-pae; KDE/4.4.5; i686; ; )
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201501080020.20326.davemgarrett@gmail.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Vv8c_P3Yk6xVN01TL_wK-7xUDU0
Cc: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>, draft-ietf-tls-prohibiting-rc4@tools.ietf.org
Subject: [TLS] draft-ietf-tls-prohibiting-rc4-01 opportunistic security
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jan 2015 05:20:25 -0000
https://datatracker.ietf.org/doc/draft-ietf-tls-prohibiting-rc4/ballot/403780/ 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
- [TLS] draft-ietf-tls-prohibiting-rc4-01 opportuni… Dave Garrett
- Re: [TLS] draft-ietf-tls-prohibiting-rc4-01 oppor… Pete Resnick