Re: [Uta] On prohibiting RC4

"Salz, Rich" <rsalz@akamai.com> Fri, 07 March 2014 12:46 UTC

Return-Path: <rsalz@akamai.com>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872671A013F for <uta@ietfa.amsl.com>; Fri, 7 Mar 2014 04:46:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.747
X-Spam-Level:
X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 LcEbaRarloQl for <uta@ietfa.amsl.com>; Fri, 7 Mar 2014 04:46:41 -0800 (PST)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBE21A0116 for <uta@ietf.org>; Fri, 7 Mar 2014 04:46:41 -0800 (PST)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8ECD1285A3; Fri, 7 Mar 2014 12:46:36 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 7ACAB285A1; Fri, 7 Mar 2014 12:46:36 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 75A3A8004F; Fri, 7 Mar 2014 12:46:36 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.104]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Fri, 7 Mar 2014 07:46:36 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Alyssa Rowan <akr@akr.io>, "uta@ietf.org" <uta@ietf.org>
Date: Fri, 07 Mar 2014 07:46:34 -0500
Thread-Topic: [Uta] On prohibiting RC4
Thread-Index: Ac85+e0TZPO0EI3tSJyrDqDoZGyu0wABH+CA
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AADD7@USMBX1.msg.corp.akamai.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AAD73@USMBX1.msg.corp.akamai.com> <5319AF96.7000407@akr.io>
In-Reply-To: <5319AF96.7000407@akr.io>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/uta/ZA2T8MhCrwcnxrSyJWtcF7JmBIk
Subject: Re: [Uta] On prohibiting RC4
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Mar 2014 12:46:42 -0000

> With respect, I think he's simply wrong, because (and we've been over this ground previously on this list, in December/January) passive
> breaks are a much greater threat than active BEAST attacks.

It depends on what you're concerned about.  From a global view, I'm concerned about perpass. From a commercial view, I'm perhaps more worried about my customers getting through to me.

> I have heard from sources I trust that NSA can passively crack RC4 in SSL/TLS in or about real-time: they are apparently doing so
> en-masse, and (importantly!) to historically-captured traffic. ...  If so, they must have really liked people switching to it to avoid the BEAST
> active attack - a mistake we should not make.

You're not seriously expecting me to take this undocumented assertion without skepticism, are you?

> BEAST attacks are active, and perpass normally has no means to perform them.

> That is not to say that those active attacks do not pose a risk, but that they pose a lower risk

Not everyone feels this way.

> so I assume you're simply playing Devil's Advocate here?

No.

> If you have any specific points or counterpoints, I'm sure we'd all love to hear them.

I'll wait until the minutes are published which will hopefully contain ekr's view which (rightfully) carries more weight than mine.

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA