Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
Watson Ladd <watsonbladd@gmail.com> Tue, 21 October 2014 00:59 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 6E14F1ACF5F for <tls@ietfa.amsl.com>; Mon, 20 Oct 2014 17:59:50 -0700 (PDT)
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 PLroTzTf4EMe for <tls@ietfa.amsl.com>; Mon, 20 Oct 2014 17:59:48 -0700 (PDT)
Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495AE1ACE8F for <tls@ietf.org>; Mon, 20 Oct 2014 17:59:48 -0700 (PDT)
Received: by mail-yh0-f49.google.com with SMTP id a41so289703yho.8 for <tls@ietf.org>; Mon, 20 Oct 2014 17:59:47 -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=Y5s+R3cf+9BC/qEc+kObxG5yNQKwcNyqDOsk9bI3Eew=; b=MrEVC8x93zEQqvQ67gg4Q1FLGapkmy7JeZQOYGZ+XcV0IZclcfyXNTaUKmSFQeUBr5 hLvDemFes7u5jPmSzWvecXlAxrb/CyzoRSEji2mrW9ySNNjh3lBFsbkxMOMc3qSJK5wT jIsObIG7WvRAC2fQ5poHqNjie4h6aj2QqlUv3rmb5MYGUsFYIY1hwfWsLcEB4bG8HWEn a+VwBV0Nt14tFi2KxcMTTMgr2XV2nFWfPGS2qS2ryoLgd4oYziP0soHTJwVHhHnPvrns OGrZJZEZvTh8XMCek5dBK4i7/sj1EFKjZke/XwE8U6YswlIasPAqCpYHigsiQx39Xwkh KQPg==
MIME-Version: 1.0
X-Received: by 10.236.1.228 with SMTP id 64mr1622839yhd.51.1413853187488; Mon, 20 Oct 2014 17:59:47 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Mon, 20 Oct 2014 17:59:47 -0700 (PDT)
In-Reply-To: <cce9c5f96fe944d5b4f6007d1c4a1bb2@BL2PR03MB419.namprd03.prod.outlook.com>
References: <20141001231254.5238.71176.idtracker@ietfa.amsl.com> <20141004033546.GG13254@mournblade.imrryr.org> <20141002175446.6EB7B1AEA6@ld9781.wdf.sap.corp> <54B025040D4F68B1E49919B8@nifty-silver.us.oracle.com> <CAOgPGoCnbHHa-PVUpyon4gp-UHZo622Y3M2fQHLWwuNv8vKnvg@mail.gmail.com> <cce9c5f96fe944d5b4f6007d1c4a1bb2@BL2PR03MB419.namprd03.prod.outlook.com>
Date: Mon, 20 Oct 2014 17:59:47 -0700
Message-ID: <CACsn0cmKojpfZFkaM8OBTZEpL0u_KFr6JEvHykm7uYE5UwRDLQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dKfrtkbPoQA1kyg6UCPRoLXorLM
Cc: "tls@ietf.org" <tls@ietf.org>
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: Tue, 21 Oct 2014 00:59:50 -0000
On Mon, Oct 20, 2014 at 5:52 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote: > The intent of draft-ietf-tls-prohibiting-rc4 is exactly what the title says: > to prohibit the use of RC4-based cipher suites in the TLS protocol. In > practice, prohibiting RC4 means that the TLS clients MUST NOT advertise RC4 > support, and the TLS servers MUST NOT select an RC4 cipher suite. Both parts > are crucially important to achieve the purpose of the I-D. > > > > If the TLS WG cannot reach rough consensus that RC4 cipher suites need to be > prohibited, then I think the way forward is for the WG to reject > draft-ietf-tls-prohibiting-rc4, and wait for the RC4 attacks to improve even > further. We've reached consensus RC4 is not a good idea. But, like Saint Augustine, "grant me strong ciphers, but not today!". That said, Chris's approach helps get us some of the way there. Sincerely, Watson Ladd > > > > In the meantime, alternative I-Ds can of course be authored to discourage > the use of RC4, although the TLS BCP already does so. > > > > Thanks, > > > > Andrei > > > > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Joseph Salowey > Sent: Saturday, October 18, 2014 11:33 AM > To: Chris Newman > Cc: tls@ietf.org > Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt > > > > The main concern that I have with this approach is that attacks against RC4 > will only get better and while the attacks may be currently impractical > against HTTP cookies perhaps there are other usages where the problem may be > greater. > > > > Pragmatically, implementers will do what is necessary to interoperate, so I > think something along the lines of what Chris recommends below may be the > best way forward. I'm a bit reluctant to bring opportunistic security > into the discussion at this point, but I think the rest is OK. > > > > Do folks think this is an acceptable way forward? > > > > Thanks, > > > > Joe > > > > > > > > On Wed, Oct 15, 2014 at 4:40 PM, Chris Newman <chris.newman@oracle.com> > wrote: > > I agree with this: > > --On October 4, 2014 3:35:47 +0000 Viktor Dukhovni <ietf-dane@dukhovni.org> > wrote: >> Well, I for one am not. Disabling RC4 does more harm than good >> with opportunistic TLS. A far better approach in that case is to >> de-priorioritize it. Giving some check-list enforcing clue-less >> auditor the ammunition to harass users into counter-productive >> "security" measures is not my idea of progress. >> ... >> Not all applications face the same risks, and removing RC4 will some >> applications *less* secure at least some of the time. > > As an implementer of a product with TLS/SSL support, I will ignore the three > MUST/MUST NOT statements in this draft. As long as the SSL/TLS library I use > supports RC4, I'm going to support RC4. And I'll be reluctant to upgrade to > an > SSL/TLS library that doesn't support RC4 for fear of breaking customer > interoperability and forcing opportunistic connections to clear text. > > I believe the goal should be to replace RC4 usage in the real world with use > of > stronger cipher suites. I do not believe the current draft will advance that > goal. Statements similar to the single-DES advice in RFC 5469 may advance > that > goal. Here are other statements that may advance that goal: > > * SSL/TLS software MUST prefer stronger cipher suites (presently AES and > 3DES) > over RC4. > > * SSL/TLS libraries MUST disable RC4 cipher suites by default. An > application > MUST make an explicit SSL/TLS library API call to enable RC4 cipher suites > if > they are needed for backwards compatibility. > > * SSL/TLS software MUST disable RC4 cipher suites when TLS 1.1 or 1.2 are > negotiated and SHOULD disable RC4 cipher suites by default when earlier > versions are negotiated. For an opportunistic security transmission, such as > for SMTP relay (RFC 3207), RC4 MAY be used as a last resort for > interoperability prior to fallback to transmission without SSL/TLS. > > * User agents that employ SSL/TLS for security MUST NOT indicate the > connection > is secure when RC4 is used. For example, a web browser that displayed a lock > icon when an RC4 cipher suite was used would fail to comply with this > requirement. > > - Chris > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > > > _______________________________________________ > 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
- [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-… internet-drafts
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Martin Rex
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Watson Ladd
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Salz, Rich
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Alyssa Rowan
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Hanno Böck
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Bodo Moeller
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Bodo Moeller
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Alyssa Rowan
- [TLS] adopting ChaCha20 as a WG item was: I-D Act… Nikos Mavrogiannopoulos
- Re: [TLS] adopting ChaCha20 as a WG item was: I-D… Yoav Nir
- Re: [TLS] adopting ChaCha20 as a WG item was: I-D… Nikos Mavrogiannopoulos
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Salz, Rich
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Bodo Moeller
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Alyssa Rowan
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Andrei Popov
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Martin Rex
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Bodo Moeller
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Alyssa Rowan
- Re: [TLS] adopting ChaCha20 as a WG item was: I-D… Yoav Nir
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Geoffrey Keating
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Viktor Dukhovni
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Watson Ladd
- [TLS] why Chacha20-SHA1 was: adopting ChaCha20 as… Nikos Mavrogiannopoulos
- Re: [TLS] why Chacha20-SHA1 was: adopting ChaCha2… Joachim Strömbergson
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Yoav Nir
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Hubert Kario
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Hubert Kario
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Viktor Dukhovni
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Watson Ladd
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Viktor Dukhovni
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Peter Gutmann
- Re: [TLS] why Chacha20-SHA1 was: adopting ChaCha2… Brian Smith
- Re: [TLS] why Chacha20-SHA1 was: adopting ChaCha2… Watson Ladd
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… James Cloos
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Paul Lambert
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Viktor Dukhovni
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Ryan Carboni
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Stephen Farrell
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Carl S. Gutekunst
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Watson Ladd
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… James Cloos
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Andrei Popov
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Martin Rex
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Yoav Nir
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Hubert Kario
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Martin Rex
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Ralph Holz
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Ronald del Rosario
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Chris Newman
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Joseph Salowey
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Andrei Popov
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Watson Ladd
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Andrei Popov
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Salz, Rich
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Alyssa Rowan
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Yoav Nir
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Ryan Carboni
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Viktor Dukhovni
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Ryan Carboni
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Salz, Rich
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Salz, Rich
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Stephen Farrell
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Paterson, Kenny
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Viktor Dukhovni
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Salz, Rich
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Hubert Kario
- [TLS] Fw: I-D Action: draft-ietf-tls-prohibiting-… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Stephen Checkoway
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Salz, Rich
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Stephen Farrell
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Salz, Rich
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Stephen Farrell
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Viktor Dukhovni
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Daniel Kahn Gillmor
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Viktor Dukhovni
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Salz, Rich
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Daniel Kahn Gillmor
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Viktor Dukhovni
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Viktor Dukhovni
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Daniel Kahn Gillmor
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Viktor Dukhovni
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Geoffrey Keating
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Viktor Dukhovni
- Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-… Blumenthal, Uri - 0558 - MITLL