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