Subject: [stir] stir-06: when will RS256 die? A future-proofing question

From: Eric Burger <[email-masked]>
Date: Thu, 10 Dec 2015 21:15:54 -0500

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.

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 15 Dec 2015 17:57:23 +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"
<[email-masked] on behalf of [email-masked]> wrote:

>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.

---

From: Russ Housley <[email-masked]>
Date: Wed, 16 Dec 2015 14:03:02 -0500

> 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 dire…

Some security protocols are specified in two RFCs.  The first one specifies the protocol and the second one specifies the mandatory-to-implement algorithms.  This approach allows the algorithm document to up updated without touching the protocol document.  We could do that here.

Russ

---

From: Eric Burger <[email-masked]>
Date: Wed, 16 Dec 2015 16:49:00 -0500

WFM. The RFC Editor has gotten much better to the point we don’t really need to care about two versus one RFC.

> On Dec 16, 2015, at 2:03 PM, Russ Housley <[email-masked]> wrote:
> 
> 
> 
>> Section 7 states:
>>  Any further values MUST

---

From: Eric Burger <[email-masked]>
Date: Tue, 15 Dec 2015 20:28:31 -0500

WFM

> On Dec 15, 2015, at 12:57 PM, Peterson, Jon <[email-masked]> wrote:
> 
>