Re: [stir] stir-06: when will RS256 die? A future-proofing question
"Peterson, Jon" <jon.peterson@neustar.biz> Tue, 15 December 2015 17:57 UTC
Return-Path: <jon.peterson@neustar.biz>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425BC1A9151 for <stir@ietfa.amsl.com>; Tue, 15 Dec 2015 09:57:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.266
X-Spam-Level:
X-Spam-Status: No, score=-102.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] 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 OWuCjHn9dFZ9 for <stir@ietfa.amsl.com>; Tue, 15 Dec 2015 09:57:29 -0800 (PST)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462631A913A for <stir@ietf.org>; Tue, 15 Dec 2015 09:57:25 -0800 (PST)
Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id tBFHvHJm000779; Tue, 15 Dec 2015 12:57:24 -0500
Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1ytfxth078-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Dec 2015 12:57:24 -0500
Received: from STNTEXMB10.cis.neustar.com ([169.254.5.186]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Tue, 15 Dec 2015 12:57:23 -0500
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: Eric Burger <eburger@standardstrack.com>, "stir@ietf.org" <stir@ietf.org>
Thread-Topic: [stir] stir-06: when will RS256 die? A future-proofing question
Thread-Index: AQHRM+GPK3Z8s7TVAEaR13qZJgjIHZ7MKgSA
Date: Tue, 15 Dec 2015 17:57:23 +0000
Message-ID: <D2958EC6.175750%jon.peterson@neustar.biz>
References: <6F39029F-5D45-42CA-9149-1489651A8E15@standardstrack.com>
In-Reply-To: <6F39029F-5D45-42CA-9149-1489651A8E15@standardstrack.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.7.151005
x-originating-ip: [192.168.128.142]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <C09444E120FE2D4B8BAE6D36B1399796@neustar.biz>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-15_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310007 definitions=main-1512150285
Archived-At: <http://mailarchive.ietf.org/arch/msg/stir/GmK_Eet8oO5TQ1c6MWIH-ukL6jQ>
Subject: Re: [stir] stir-06: when will RS256 die? A future-proofing question
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Dec 2015 17:57:30 -0000
I think saying "MUST support anything until deprecated" is tautologous, as all MUSTs can be deprecated. Similarly I don't think we need to tell people to check future RFCs for updates any more than any other RFC does. I think the text we have is normal for specifications like ours. But the basic idea here is to provide emergency algorithm agility while reducing bid-down attacks by limiting options. Jon Peterson Neustar, Inc. On 12/10/15, 6:15 PM, "stir on behalf of Eric Burger" <stir-bounces@ietf.org on behalf of eburger@standardstrack.com> wrote: >Section 7 states: > Any further values MUST > be defined in a Standards Track RFC, see Section 12.2 for more > information. All implementations of this specification MUST support > 'RS256'[EB1] . > >So when RS256 gets compromised, we have to reissue the entire 4474bis? >Or, is this a built-in downgrade attack? Maybe "MUST support 'RS256' >until RS256 becomes deprecated.² Or, maybe, since we directly say to have >a new algorithm requires a Standards Track RFC, such RFC could update >this one. If we are thinking that, then we should say something like >³check the RFC Editor data base for updates for this specification.² I >know, people should do that no matter what they are doing, but who does? >This is something important, and could be a downgrade attack if we do not.
- [stir] stir-06: when will RS256 die? A future-pro… Eric Burger
- Re: [stir] stir-06: when will RS256 die? A future… Peterson, Jon
- Re: [stir] stir-06: when will RS256 die? A future… Russ Housley
- Re: [stir] stir-06: when will RS256 die? A future… Eric Burger
- Re: [stir] stir-06: when will RS256 die? A future… Eric Burger