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

Paul Lambert <paul@marvell.com> Sat, 04 October 2014 02:46 UTC

Return-Path: <paul@marvell.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 B828F1A8A47 for <tls@ietfa.amsl.com>; Fri, 3 Oct 2014 19:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Level:
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 Y33ZhHMgd0Gn for <tls@ietfa.amsl.com>; Fri, 3 Oct 2014 19:46:32 -0700 (PDT)
Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F531A8877 for <tls@ietf.org>; Fri, 3 Oct 2014 19:46:31 -0700 (PDT)
Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s942kUV2013158 for <tls@ietf.org>; Fri, 3 Oct 2014 19:46:30 -0700
Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0a-0016f401.pphosted.com with ESMTP id 1pt1v20nkh-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <tls@ietf.org>; Fri, 03 Oct 2014 19:46:30 -0700
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA03.marvell.com ([::1]) with mapi; Fri, 3 Oct 2014 19:46:30 -0700
From: Paul Lambert <paul@marvell.com>
To: "tls@ietf.org" <tls@ietf.org>
Date: Fri, 03 Oct 2014 19:46:29 -0700
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
Thread-Index: Ac/fDkNroYyw+zfzSiSSroHPeJluhwAbN1Kw
Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D020DE17B869@SC-VEXCH2.marvell.com>
References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <BA2DFF33-7B0C-4E87-9C0E-215933AED88F@akr.io> <2A0EFB9C05D0164E98F19BB0AF3708C71D2F8F7E83@USMBX1.msg.corp.akamai.com> <CADMpkcJEt4e7LJAY+FsFcbyQE2x3SXsaOW3bffV4U2oN9EUKrg@mail.gmail.com> <542D850E.2060900@akr.io> <CADMpkc+Zbu64wek2HayW2tCf+d1ZYLocMp2PzXncyS=fHPDwsg@mail.gmail.com> <542DB1D4.4020601@akr.io> <20141003042418.GS13254@mournblade.imrryr.org> <CACsn0cnr49RHoNDhy=x7+Da=v4X=6rSMWKazA-ZObPTsuZnsGA@mail.gmail.com> <20141003133043.GV13254@mournblade.imrryr.org>
In-Reply-To: <20141003133043.GV13254@mournblade.imrryr.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-04_01:2014-10-03,2014-10-03,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410040031
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZYtlSH8Gxksnue5sPMZCIMetUDY
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: Sat, 04 Oct 2014 02:46:33 -0000

]Before RC4 becomes MUST NOT, it needs to first become a low priority
]algorithm that is used when nothing better is available.

We are over thinking the presumed interoperability concerns.

There are no RFC police to enforce SHOULD versus MUST. There
will not be a red-flag day when RC4 is apparently turned off 
with a "MUST NOT" in a document from this group. 

A 'SHOULD NOT' recommendation is readily ignored. There is no
clear guidance, only a suggestion.  Guidance on industry practice
for such a feature is very important to help determine diligence
of an implementation to follow recommended industry practice.

A 'MUST NOT', could be ignored, but installations that are audited
for compliance to "recommended industry practice" would be dinged.
This introduces potential liability and financial risks that would
encourage the removal of RC4.

'SHOULD NOT' carries no incentive for change.
'MUST NOT' provides clear guidance and incentive that will still 
take many years to be adopted fully.


Paul