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

Hubert Kario <hkario@redhat.com> Thu, 23 October 2014 13:48 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 43AEB1A8AFE for <tls@ietfa.amsl.com>; Thu, 23 Oct 2014 06:48:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 Kgs6UFetU-pm for <tls@ietfa.amsl.com>; Thu, 23 Oct 2014 06:48:33 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96951A90F3 for <tls@ietf.org>; Thu, 23 Oct 2014 06:48:31 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9NDVRLZ014226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 23 Oct 2014 09:31:28 -0400
Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9NDVPxR001887 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2014 09:31:26 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Thu, 23 Oct 2014 15:31:24 +0200
Message-ID: <2692021.SmcXNkosgU@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.1 (Linux/3.16.6-200.fc20.x86_64; KDE/4.14.1; x86_64; ; )
In-Reply-To: <20141023060003.GM19158@mournblade.imrryr.org>
References: <CAO7N=i3gC=+qcgHU=aMKtRyT7tZV5fm=9gJii-=yOpcNECOEvA@mail.gmail.com> <544837FD.202@cs.tcd.ie> <20141023060003.GM19158@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dI5bcPTbCKeZa6QYi4rnqJKU_ec
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: Thu, 23 Oct 2014 13:48:36 -0000

On Thursday 23 October 2014 06:00:03 Viktor Dukhovni wrote:
> On Thu, Oct 23, 2014 at 12:04:29AM +0100, Stephen Farrell wrote:
> > > So I think that it would be nice if there was some wiggle-room for
> > > opportunistic TLS.  As weak as RC4 might be, it is stronger than
> > > cleartext.  And the published bias attacks don't apply to MTA to
> > > MTA SMTP.  There is no (pairwise) fixed sensitive plaintext at a
> > > fixed offset in every MTA to MTA email transaction.
> > > 
> > > I have no objections to banning RC4 for "strict" TLS use-cases.
> > 
> > I think there is a significant difference between the security
> > (in particular confidentiality) one gets with good and dodgy
> > algorithms which is sufficient to argue that the OS design
> > pattern is inappropriate to use with such dodgy algs.
> 
> I'd very much like to agree with you this year.  My concern is that
> for now, there are still too many RC4-only sites, and disabling
> RC4 will do more harm (in opportunistic TLS) than good in two ways:
> 
>     * Some communication will needlessly fall back to cleartext
>       after STARTTLS fails, which might have succeeded with RC4.
> 
>     * Some communication will not fall back, and force users to
>       statically downgrade transmission to cleartext by policy.
>       Said policy will rarely get reviewed, and the RC4-only peers
>       will be "pinned" at cleartext even after they upgrade.

Looking at web servers, less than 1% support only RC4 ciphers, the
rest of the 21% that end up negotiating RC4 will gladly negotiate
different ciphers (mostly AES based ones) if the client doesn't offer
RC4.

> If excluding opportunistic security is too painful, and it is better
> for the draft to have an undiluted message than a nuanced one based
> on more pragmatic considerations, fine, so be it, make it pure.
> We'll muddle along violating it as necessary.

How long since we got to know that RC4 is really bad? And this draft
is still not an RFC. Let's say that we will change it to say that the RC4 MUST 
be placed last (both client and server side) and release it today. How long 
will it take to release a new RFC that says that it MUST NOT be used?
How long will it take for majority (let's say 75%) of server admins that are 
not compliant with it to actually implement this policy? How many of them will 
unknowingly ignore it?

Just those issues in itself will cause the RC4 depreciation to have a de facto 
transition period. Just look for statistics of the OpenSSL CCS and Hartbleed 
fixes deployments, and those were security vulnerabilities, not best practice 
recommendations.

Second issue is that opportunistic encryption is completely vulnerable to 
active MITM attack, isn't it? This in itself makes it non-RFC compliant, at 
the very least, from the TLS point of view.

-- 
Regards,
Hubert Kario