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, 8 Aug 2014 15:36:28 +0200 (CEST)
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 (Martin Rex)
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