Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

Andrei Popov <Andrei.Popov@microsoft.com> Tue, 21 October 2014 05:14 UTC

Return-Path: <Andrei.Popov@microsoft.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 3094F1AD051 for <tls@ietfa.amsl.com>; Mon, 20 Oct 2014 22:14:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 kx4hMWgai0ye for <tls@ietfa.amsl.com>; Mon, 20 Oct 2014 22:13:57 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0776.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::776]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331011AD050 for <tls@ietf.org>; Mon, 20 Oct 2014 22:13:57 -0700 (PDT)
Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB420.namprd03.prod.outlook.com (10.141.92.25) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Tue, 21 Oct 2014 05:13:33 +0000
Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1054.004; Tue, 21 Oct 2014 05:13:33 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Watson Ladd <watsonbladd@gmail.com>
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
Thread-Index: AQHP3c1Ub4FUPtdXakGIHJMHMTXmG5wx5z5wgARg/gCAA4jTEIAAB/SAgABE+8Q=
Date: Tue, 21 Oct 2014 05:13:33 +0000
Message-ID: <1413868526423.88894@microsoft.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>, <CACsn0cmKojpfZFkaM8OBTZEpL0u_KFr6JEvHykm7uYE5UwRDLQ@mail.gmail.com>
In-Reply-To: <CACsn0cmKojpfZFkaM8OBTZEpL0u_KFr6JEvHykm7uYE5UwRDLQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [50.46.226.201]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB420;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 0371762FE7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(55674003)(24454002)(51704005)(189002)(377454003)(164054003)(199003)(31966008)(20776003)(64706001)(105586002)(106116001)(66066001)(106356001)(4396001)(99286002)(95666004)(107046002)(110136001)(86612001)(87936001)(230783001)(40100003)(122556002)(76176999)(93886004)(85306004)(54356999)(15975445006)(85852003)(2656002)(19580405001)(19580395003)(50986999)(21056001)(1411001)(92566001)(46102003)(76482002)(92726001)(86362001)(99396003)(80022003)(36756003)(120916001)(101416001)(117636001)(97736003)(22906005); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB420; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7sswUKTgHPN5Ka0cxF7Kzch-oWM
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 05:14:00 -0000

Chris's language reads weaker than the TLS BCP, but if folks want to pursue this, that's up to the WG. My point is that this should be a different I-D, because it does not amount to "prohibiting RC4".

Cheers,

Andrei
________________________________________
From: Watson Ladd <watsonbladd@gmail.com>
Sent: Monday, October 20, 2014 5:59 PM
To: Andrei Popov
Cc: Joseph Salowey; Chris Newman; tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

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