Re: [Uta] On prohibiting RC4
Martin Thomson <martin.thomson@gmail.com> Sat, 08 March 2014 07:12 UTC
Return-Path: <martin.thomson@gmail.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 3961D1A01F2 for <uta@ietfa.amsl.com>; Fri, 7 Mar 2014 23:12:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pV4W-nYDZGnN for <uta@ietfa.amsl.com>; Fri, 7 Mar 2014 23:12:43 -0800 (PST)
Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6F31A01F9 for <uta@ietf.org>; Fri, 7 Mar 2014 23:12:43 -0800 (PST)
Received: by mail-we0-f179.google.com with SMTP id x48so6234052wes.10 for <uta@ietf.org>; Fri, 07 Mar 2014 23:12:38 -0800 (PST)
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=rDftmGksWXkspkkMcJj5PAtbhFEaBWg1h9RaR/DVS84=; b=DVZOas8XoB6/QoR+/ggXis+I5zc2HgFkhVU6cA3A8QNHO/+qDpcR0+ZCgM6Un996Qa EjV2KpK72Ghj74720rS3OMJVdEmjSeWKwH+4wn9MUc7NgHoEBtBCf2yrAVOY3iMCElwl /5YIxNmj5n7QZwNxIpeqFOCKheiU6RrX/TChPvlw2U1+358GKlNQGOmIDLewfA9WMpfh WXivreWum1Z2OjdGlbtJT+W0JfUESq8Bbbo8yb+6LEBuNvOMTo8Hk6n8oA5oxtf2jMyO hsCgw/soaxFyqj+Iq3BfyhroDFUHkTfASwwaXu8dh5DpNYkylLPoKsa/7onU2wL8rvjc uqfw==
MIME-Version: 1.0
X-Received: by 10.180.185.197 with SMTP id fe5mr1650461wic.56.1394262758443; Fri, 07 Mar 2014 23:12:38 -0800 (PST)
Received: by 10.227.10.196 with HTTP; Fri, 7 Mar 2014 23:12:38 -0800 (PST)
In-Reply-To: <531AAEC7.4060409@gmail.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AAD73@USMBX1.msg.corp.akamai.com> <5319AF96.7000407@akr.io> <2A0EFB9C05D0164E98F19BB0AF3708C711FB9AADD7@USMBX1.msg.corp.akamai.com> <147c6c280e2044ac97624762410872ff@BL2PR03MB419.namprd03.prod.outlook.com> <531AAEC7.4060409@gmail.com>
Date: Sat, 08 Mar 2014 07:12:38 +0000
Message-ID: <CABkgnnWKZ4N-b-f3igCp-9032D5x87CVp63b2kVayd5nNv5gcw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/uta/Q90CRj-DSyanm8R0hPY7f80D3Io
Cc: Alyssa Rowan <akr@akr.io>, "Salz, Rich" <rsalz@akamai.com>, Andrei Popov <Andrei.Popov@microsoft.com>, "uta@ietf.org" <uta@ietf.org>
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: Sat, 08 Mar 2014 07:12:46 -0000
On 8 March 2014 05:46, Yaron Sheffer <yaronf.ietf@gmail.com> wrote: > If we're saying MUST NOT we must be able to stand behind it. If we can't, > let's try to craft more nuanced language. I think that the difference is between "prohibited" and "deprecated". I think that at this stage, the intent is to say "Implementations MUST NOT use RC4 unless there are no better options." Definition of "better", TBD. Probably, at this point, everything else that is not also deprecated. I'd hope that this doesn't mean that implementations have to implement the fallback Andrei has. That mostly seems to be a way for the client to influence the choice, though I note that penalizing servers who deploy RC4 is an interesting idea. It does mean that a server cannot accept RC4 when better options are available. It also means that perhaps clients should fail the handshake in cases where the server negotiates RC4, unless we decide that 3DES is strictly worse. My understanding was that 3DES was only bad from a performance perspective, but I'm not going to try to persuade Rick one way or the other there :) I hope that it would be uncontroversial if we said that clients should fail the handshake in the case that TLS 1.2 is negotiated.
- Re: [Uta] On prohibiting RC4 Alyssa Rowan
- [Uta] On prohibiting RC4 Salz, Rich
- Re: [Uta] On prohibiting RC4 Alyssa Rowan
- Re: [Uta] On prohibiting RC4 Salz, Rich
- Re: [Uta] On prohibiting RC4 Salz, Rich
- Re: [Uta] On prohibiting RC4 Alyssa Rowan
- Re: [Uta] On prohibiting RC4 Andrei Popov
- Re: [Uta] On prohibiting RC4 Franck Martin
- Re: [Uta] On prohibiting RC4 Joe St Sauver
- Re: [Uta] On prohibiting RC4 Yaron Sheffer
- Re: [Uta] On prohibiting RC4 Martin Thomson
- Re: [Uta] On prohibiting RC4 Yaron Sheffer
- Re: [Uta] On prohibiting RC4 Martin Thomson
- Re: [Uta] On prohibiting RC4 Andrei Popov