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

Hubert Kario <hkario@redhat.com> Mon, 06 October 2014 20:17 UTC

Return-Path: <hkario@redhat.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 E46F21A8961 for <tls@ietfa.amsl.com>; Mon, 6 Oct 2014 13:17:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.688
X-Spam-Level:
X-Spam-Status: No, score=-7.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, 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 GEi4uIoIuM4z for <tls@ietfa.amsl.com>; Mon, 6 Oct 2014 13:17:25 -0700 (PDT)
Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 443101A8965 for <tls@ietf.org>; Mon, 6 Oct 2014 13:17:24 -0700 (PDT)
Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s96KHNPN009260; Mon, 6 Oct 2014 16:17:23 -0400
Date: Mon, 6 Oct 2014 16:17:22 -0400 (EDT)
From: Hubert Kario <hkario@redhat.com>
To: mrex@sap.com
Message-ID: <1381566393.7039054.1412626641999.JavaMail.zimbra@redhat.com>
In-Reply-To: <20141006195844.ED7D61AEB1@ld9781.wdf.sap.corp>
References: <20141006195844.ED7D61AEB1@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.5.82.7]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF32 (Linux)/8.0.6_GA_5922)
Thread-Topic: I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
Thread-Index: YluHgyEumeMc8PBPH24lZb6rwGI0hA==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PmD_Ppw551gxgA2Vcx0USaVKPd8
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
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 20:17:29 -0000

----- Original Message -----
> From: "Martin Rex" <mrex@sap.com>
> To: "Hubert Kario" <hkario@redhat.com>
> Cc: tls@ietf.org
> Sent: Monday, 6 October, 2014 9:58:44 PM
> Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
> 
> 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.

that doesn't increase security against targeted attacks, which are
basically the only ones against which we need protection
 
> 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.

thing is that only very specific clients do advertise only RC4,
far less than there are RC4 only servers. Cloudflare saw on the
order of 0.000002% of connections end up with RC4:
http://blog.cloudflare.com/the-web-is-world-wide-or-who-still-needs-rc4/
All from long obsolete clients.

Previously they saw on the order of 0.0009%:
http://blog.cloudflare.com/killing-rc4-the-long-goodbye/


-- 
Regards,
Hubert Kario