Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00
mrex@sap.com (Martin Rex) Fri, 08 August 2014 13:36 UTC
Return-Path: <mrex@sap.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 45BC31B28D0 for <tls@ietfa.amsl.com>; Fri, 8 Aug 2014 06:36:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-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 SpEHqyO91VkJ for <tls@ietfa.amsl.com>; Fri, 8 Aug 2014 06:36:33 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 48ED61B28AD for <tls@ietf.org>; Fri, 8 Aug 2014 06:36:33 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s78DaSjS009091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Aug 2014 15:36:28 +0200 (MEST)
In-Reply-To: <28ABE4ED-F5E5-4561-9A47-27EE2551A15B@ieca.com>
To: Sean Turner <TurnerS@ieca.com>
Date: Fri, 08 Aug 2014 15:36:28 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140808133628.7C9931ADFC@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1PHsGga_wDviQhwul74USZC1t6c
Cc: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Subject: Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 08 Aug 2014 13:36:36 -0000
Sean Turner wrote: > > This is the working group last call for draft-ietf-tls-prohibiting-rc4-00: > http://datatracker.ietf.org/doc/draft-ietf-tls-prohibiting-rc4/ > Please send comments on this draft to the TLS list before August 23, 2014. The RC4 cipher suites are still stronger than the EXPORT40 and EXPORT56 cipher suites, because for the latter, even one singular session can be successfully attack and *completely decrypted* in most cases, whereas the weaknesses currently known for RC4 cipher suites allow an attacker to recover only the plaintext equivalent of a static "disclosing authentication" (password or token) after 2^20+ TLS session. I therefore object to the Bullets 2 & 3 of section 2, (I'm OK with bullet 1): 2. Changes to TLS Because of the deficiencies noted in Section 1: o TLS clients MUST NOT include RC4 cipher suites in the ClientHello message. o TLS servers MUST NOT select an RC4 cipher suite when a TLS client sends such a cipher suite in the ClientHello message. o If the TLS client only offers RC4 cipher suites, the TLS server MUST terminate the handshake. The TLS server MAY send the insufficient_security fatal alert in this case. It should be left to the local policy of the server whether to agree to the use of an RC4 cipher suite rather than fail the connection. Servers should NEVER let the client-side ordering of cipher suites in ClientHello take precedence over the servers' preference, and RC4 cipher suites, similar to EXPORT40 and EXPORT56 cipher suites should never take precedence over stronger cipher suites that client and server have in common, just because they happen to appear earlier in the list in ClientHello. Especially in the Web, where access to information is often available through HTTP and HTTPS, a policy like the above (when adopted) would cause MORE communication to be performed in plaintext. There currently exists *no* known attack against the integrity protection of the TLS handshake, so this looks primarily like an attempt to promote "planned obsolesence", and a poor excuse for Microsoft to actively break interop with Windows XP (and potentially other installed base). -Martin
- [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 Sean Turner
- Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 Martin Rex
- Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 Alyssa Rowan
- Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 Hubert Kario
- Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 Martin Rex
- Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 Hubert Kario
- Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 Martin Rex
- Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 Paul Lambert
- Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 Aaron Zauner