Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac)
Watson Ladd <watsonbladd@gmail.com> Tue, 15 April 2014 02:12 UTC
Return-Path: <watsonbladd@gmail.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 1CF011A02E5 for <tls@ietfa.amsl.com>; Mon, 14 Apr 2014 19:12:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 gnzFCooQ8mhg for <tls@ietfa.amsl.com>; Mon, 14 Apr 2014 19:12:00 -0700 (PDT)
Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A0A2B1A0259 for <tls@ietf.org>; Mon, 14 Apr 2014 19:12:00 -0700 (PDT)
Received: by mail-yh0-f45.google.com with SMTP id a41so8759079yho.4 for <tls@ietf.org>; Mon, 14 Apr 2014 19:11:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k8DCkZYdIWwCVxMZ40TEdEB6ax+iNPs+Wi0ctkW+uUE=; b=c9+pJwC60Yv6DGQR2MXlHZmt/QVLc1hBp8IDylHAPooIpL9Hdhg4eSJHyCtHh8QsXc sY1JlieXqkJ+6nFkaT+PvAKAVUdKWf1HxWTi7RNm9COHzkr8zsx6ugUHQNT52L6tWiMF OLeHySu0A4BDzP9/4DjIP5qGwQqJ6VrG5+pob9x/K3iFb4lrQoUZejqJpbeAcn911azd DX0sUjhN0bXa/HOc8Q0gHy9ffCuY4CGoUcTg38h//FeQ9LpW/GvrxD99MgYC6u30eh4B opTKNHNJiM+z9j1Q43MtE90jl71d11TtjHxo27snNvA+o3T33XeXrGSDnq8+PTZD16gx fTmw==
MIME-Version: 1.0
X-Received: by 10.236.162.65 with SMTP id x41mr61688358yhk.25.1397527917797; Mon, 14 Apr 2014 19:11:57 -0700 (PDT)
Received: by 10.170.63.197 with HTTP; Mon, 14 Apr 2014 19:11:57 -0700 (PDT)
In-Reply-To: <20140415005124.1D8D01ACBF@ld9781.wdf.sap.corp>
References: <CABkgnnWppZ4C7AvTOvfyRtRmTHTfq-i5BiUFxBMZx9gAYL_+5g@mail.gmail.com> <20140415005124.1D8D01ACBF@ld9781.wdf.sap.corp>
Date: Mon, 14 Apr 2014 19:11:57 -0700
Message-ID: <CACsn0cmQDKr8CmGY-AsBtOwrS0LEaYvL9vLgJW35TggS31bm7Q@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: mrex@sap.com
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3iMP1EAfeldXNbue-wILQIsQthw
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac)
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: Tue, 15 Apr 2014 02:12:05 -0000
On Mon, Apr 14, 2014 at 5:51 PM, Martin Rex <mrex@sap.com> wrote: > Martin Thomson wrote: > [ Charset UTF-8 unsupported, converting... ] >> On 14 April 2014 14:33, Martin Rex <mrex@sap.com> wrote: >> > There might be (higher layer) protocols that do this all by themselves >> > (resend the very same data over and over again) potentially including >> > credentials of a disclosing authentication, and there might be >> > communication peers that can be enticed to do this (such as web browsers). >> >> I'm pretty sure that both instances of "might be" can be replaced by >> "are". Web browsers use HTTP in this way. Hence the desire to end >> RC4 use, at least in that context. > > I don't think so. A TLS protected communication involves two communication > peers, and web browsers are only a fraction of the communication peers > in existence (less than half). > > Web Browsers, in particular those that aggressively execute everything > that is sent to them in one way or another, may want to deprecate RC4-based > cipher suites fairly quickly. They're free to do so. > > But the story is different for TLS peers which are less aggressive about > executing attacker-supplied active content, and it is different for > servers, which do not have the option of a reconnect fallback. It really isn't. If you look at the graphs presented in the 2013 RC4 paper (and you did look at this paper, right?), you will see they ignore two things: the fact that plaintext usually has structure, and the cross-byte correlations which are known to exist. That's why RC4 is dead: the initial bytes are just icing on the cake for a serious attacker. Furthermore, the reason browsers have been unable to drop RC4 entirely is misconfigured servers that offer only RC4. Moving away from RC4 needs to begin now. Lastly, at what point do you want us to call RC4 broken? Academic cryptographers had a spate of results against it 2001-2002, culminating in wepcracker. When WEP was replaced by WPA, this stopped being so interesting, and I think 90% of them would have recommend against continuing to use it at that point. However, I'm sure Fort Meade has keep looking. (By the way, TLS was supposed to make everything web browsers do to it now perfectly safe. That's where it was designed) > > > What should be done, similar to previous documents of that kind, > is provide a useful rationale to the readers of the document, so that > they can make a conscious decision and security trade-off between > interoperability with an installed base and a potential risk of > plaintext recovery under specific, and not necessarily regular conditions. We don't know what those conditions are. The cryptanalysis of RC4 is by no means over. By no means should TLS 1.3 continue to allow its use. > > > Other examples for rationales: > > MD2: https://tools.ietf.org/html/rfc6149#section-2 > MD4: https://tools.ietf.org/html/rfc6150#section-2 > MD5: https://tools.ietf.org/html/rfc6151#section-2 > SSLv2: https://tools.ietf.org/html/rfc6176#section-2 > > DES in TLS: https://tools.ietf.org/html/rfc5469#section-4 > DES in Kerberos: https://tools.ietf.org/html/rfc6649#section-4 All of which came years or in some cases a decade late. DES cracker systems existed in 1998. MD5 was broken in 2004, as was MD4. The IETF has a crypto problem: we are terrible at getting rid of broken systems, or at responding appropriately. SHA-1 belongs on that list: collisions in 2^63 time. > > > > Personally, I would consider it irresponsible to publish an > RFC for deprecation of RC4-based TLS cipher suites *WITHOUT* > an adequate rationale / security considerations. Irresponsible why? Perhaps because it isn't convincing. But to me the existence of 2001's Flueher-McGrew biases makes RC4 unfit for purpose. Sincerely, Watson Ladd > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Matt Caswell
- [TLS] Deprecating RC4 (was: draft-ietf-tls-encryp… Eric Rescorla
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Martin Thomson
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Kurt Roeckx
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Daniel Kahn Gillmor
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Peter Yee
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Andrei Popov
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Stephen Checkoway
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Yoav Nir
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Geoffrey Keating
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Jim Schaad
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Manuel Pégourié-Gonnard
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Johannes Merkle
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Stephen Farrell
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Richard Hartmann
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Yoav Nir
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Warren Kumari
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Eric Rescorla
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Martin Rex
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Martin Thomson
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Martin Rex
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Watson Ladd
- Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-en… Bill Frantz
- [TLS] Deprecating more (DSA?) (was Re: Deprecatin… Hanno Böck
- Re: [TLS] Deprecating more (DSA?) (was Re: Deprec… Yoav Nir
- Re: [TLS] Deprecating more (DSA?) (was Re: Deprec… Hanno Böck
- Re: [TLS] Deprecating more (DSA?) (was Re: Deprec… Daniel Kahn Gillmor
- Re: [TLS] Deprecating more (DSA?) (was Re: Deprec… Hanno Böck
- Re: [TLS] Deprecating more (DSA?) (was Re: Deprec… Tom Ritter
- Re: [TLS] Deprecating more (DSA?) Alyssa Rowan
- Re: [TLS] Deprecating more (DSA?) Joseph Salowey (jsalowey)
- Re: [TLS] Deprecating more (DSA?) Watson Ladd
- Re: [TLS] Deprecating more (DSA?) Alyssa Rowan
- Re: [TLS] Deprecating more (DSA?) Johannes Merkle
- Re: [TLS] Deprecating more (DSA?) Brian Sniffen
- Re: [TLS] Deprecating more (DSA?) Bill Frantz
- Re: [TLS] Deprecating more (DSA?) Watson Ladd
- Re: [TLS] Deprecating more (DSA?) Samuel Neves
- Re: [TLS] Deprecating more (DSA?) Bill Frantz