Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

mrex@sap.com (Martin Rex) Mon, 06 October 2014 19:59 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 536021A8970 for <tls@ietfa.amsl.com>; Mon, 6 Oct 2014 12:59:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 EQXMI1Gey5RQ for <tls@ietfa.amsl.com>; Mon, 6 Oct 2014 12:59:00 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84FB81A8983 for <tls@ietf.org>; Mon, 6 Oct 2014 12:58:47 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 4F7AB7A276; Mon, 6 Oct 2014 21:58:45 +0200 (CEST)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 037FE42E14; Mon, 6 Oct 2014 21:58:45 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id ED7D61AEB1; Mon, 6 Oct 2014 21:58:44 +0200 (CEST)
In-Reply-To: <1878200851.5790803.1412334914571.JavaMail.zimbra@redhat.com>
To: Hubert Kario <hkario@redhat.com>
Date: Mon, 6 Oct 2014 21:58:44 +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: <20141006195844.ED7D61AEB1@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1gUPylsqxXHBwCsU-KB3RCbs_sw
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
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: Mon, 06 Oct 2014 19:59:07 -0000

Hubert Kario wrote:
> 
> Only about 1% of servers support only RC4 cipher, 1.5% if you're
> using Firefox[1].
> 
> On the other hand, over 21% of servers will negotiate a RC4 cipher
> in case you're using Firefox (and nearly 18% if you're using
> OpenSSL-like supported cipher list).
> 
> So by dropping RC4 from your first ClientHello (in case you do use
> fallback) may as well cut your RC4 usage by over 20%!

We're talking past each other here.

I'm perfectly OK with the MUST NOT for the __client__ (!!), and
I will not mind the slightest if (Browser or other) TLS clients that
implement the awkward application-level reconnect fallback logic
for TLS handshake failures start "punishing" the remaining RC4-only
servers with reconnect fallbacks.

My issue is with the IMHO bogus "MUST NOT" for servers.
Servers have no control over the client behaviour, and the current
proposal calls for an unconditional hard failure (equals to
"come back in clear text") rather than interoperating with an
RC4-based TLS cipher suites with installed base clients.

Based on what we currently know about the weaknesses of RC4,
unconditionally turning down clients will be ridiculously stupid
in most situations, because for the vast number of scenarios,
the weakness of the TLS RC4 cipher suites is not a threat.


-Martin