[secdir] secdir review of draft-ietf-tls-prohibiting-rc4-01

Tom Yu <tlyu@mit.edu> Wed, 10 December 2014 00:21 UTC

Return-Path: <tlyu@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186F01A0399; Tue, 9 Dec 2014 16:21:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 xTbpLncbOy_y; Tue, 9 Dec 2014 16:21:18 -0800 (PST)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 775AE1A0318; Tue, 9 Dec 2014 16:21:18 -0800 (PST)
X-AuditID: 12074425-f798e6d000000d1a-5e-548791fd8c14
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id C5.90.03354.DF197845; Tue, 9 Dec 2014 19:21:17 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id sBA0LGLA027073; Tue, 9 Dec 2014 19:21:16 -0500
Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sBA0LEAj028994; Tue, 9 Dec 2014 19:21:15 -0500
From: Tom Yu <tlyu@mit.edu>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tls-prohibiting-rc4.all@tools.ietf.org
Date: Tue, 09 Dec 2014 19:21:13 -0500
Message-ID: <ldviohks6bq.fsf@sarnath.mit.edu>
Lines: 24
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEIsWRmVeSWpSXmKPExsUixCmqrPt3YnuIwYpXwhar985kspjxZyKz xYeFD1kcmD2WLPnJ5PHl8me2AKYoLpuU1JzMstQifbsErow/x1+yFMziqvj8fiFzA+Nyji5G Tg4JAROJzeefsELYYhIX7q1n62Lk4hASWMwksW/VckYIZwOjxKYVO5ghnNeMEguv/mUCaWET kJY4fnkXmC0iECex/WMfmC0sYC0xvfcSmM0ioCrRe/oxG4jNK6Arced0PzOIzSPAKTH5Ww8z RFxQ4uTMJywgNrOAlsSNfy+ZJjDyzkKSmoUktYCRaRWjbEpulW5uYmZOcWqybnFyYl5eapGu hV5uZoleakrpJkZQULG7qO5gnHBI6RCjAAejEg+vhmVbiBBrYllxZe4hRkkOJiVR3is17SFC fEn5KZUZicUZ8UWlOanFhxglOJiVRHjXsgDleFMSK6tSi/JhUtIcLErivJt+8IUICaQnlqRm p6YWpBbBZGU4OJQkeL9PAGoULEpNT61Iy8wpQUgzcXCCDOcBGn4QpIa3uCAxtzgzHSJ/ilFR Spz3FkhCACSRUZoH1wuL+leM4kCvCPP2glTxABMGXPcroMFMQINfJLaCDC5JREhJNTDOTFhp 8J0lpmZKlFvUjZRLfguZFOpLdTZ6NR0UCPJgP711heauTVvnWM/4mNIeo8Hy6MqikmuzOjZ/ Z1KTOaSnoBrP0jztTsuxVrn1WVtkdk26Mnmf3cblaR5d0Zsbot9/k/q23aWze8X/ZzZPXK4a ruWo3NF23v6czEz+bQ3ZU56z6F15sX+dEktxRqKhFnNRcSIAFyhDpNUCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/kk0GZru3HqolZrE-221riBIcWjY
Subject: [secdir] secdir review of draft-ietf-tls-prohibiting-rc4-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Dec 2014 00:21:23 -0000

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

Summary: ready with minor issues

This document deprecates RC4 cipher suites in TLS due to attacks that
can recover repeated plaintexts given about 2^26 sessions.  Accordingly,
it says that TLS implementations MUST NOT use RC4 cipher suites.

However, I noticed that RFC 5469 specifies only "SHOULD NOT" for
single-DES cipher suites in TLS.  I don't know whether a 2^56 offline
exhaustive key search that reveals an initial plaintext is directly
comparable to a 2^26 online attack that reveals the entire plaintext,
but it seems odd that single-DES is only "SHOULD NOT" while RC4 is "MUST
NOT".  Perhaps this document is not the right place to fix that
discrepancy.

On the other hand, I am wondering if an unintended consequence of sites
or implementations disabling RC4 cipher suites is falling back to
single-DES.  What prevents this fallback from happening?  I don't have a
lot of the relevant information about TLS implementations as deployed.