[jose] Re: Review: draft-ietf-jose-deprecate-none-rsa15-01

Mon, 24 Mar 2025 04:55:34 -0700

Thank you Neil for writing this draft and for your responses. I’m glad you have a good sense of what “deprecate” means – I’ve been to too many discussions about nuances of this word.

 

                Yaron

 

From: Neil Madden <[email protected]>
Date: Monday, 24 March 2025 at 12:33
To: Yaron Sheffer <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: [jose] Review: draft-ietf-jose-deprecate-none-rsa15-01

Hi Yaron,

 

Thanks for this review, it’s much appreciated. Responses inline below:



On 21 Mar 2025, at 16:31, Yaron Sheffer <[email protected]> wrote:

 

As promised at the Bangkok session, here goes. Despite my comments below, I am supportive of progressing the draft to WGLC, hopefully after these are addressed.

  • Apologies for opening an issue that's only marginally in scope for this draft, but: the IANA registration for "none" specifies that it appears in the "alg" header parameter. However "alg" is defined for JWS (of course) but also for JWE. So - and correct me if I'm wrong - an implementer would still be compliant if they interpreted "none" as "do not encrypt" within JWE. Yes, the description in the IANA registry says "No digital signature or MAC performed" but I think a stronger separation is called for. In fact I don't understand why we have a single registry for both "key management" and integrity protection algorithms, where we don't say which can be used in which situation. (Sec. 7.1.1 of RFC 7518 does not require that a registration of an "alg" should include an indication whether it's legal for JWS, JWE or both, despite the fact that this RFC itself is actually quite clear about the usage of algorithms that it defines itself).

 

 

Well, yes, this is a historical problem with JOSE that a single header is used for both JWS and JWE algorithms. Regarding "an implementer would still be compliant if they interpreted "none" as "do not encrypt" within JWE”, RFC 7518 section 3.6 (which is the reference for “none”) only defines it for JWS, so I don’t think this would be compliant.



  •  
  • Personally I am skeptical of the utility of formally deprecating None. I think libraries that still accept it are unlikely to change as a result of this RFC. But apparently I'm in the rough on that, plus the deprecation of RSA1_5 actually is important, IMHO.
  • When first referencing RFC 8017, please include the exact section (7.2, as far as I can tell), because there's a lot of stuff there that's still secure.

 

 



  •  
  • And to my first point about "alg" confusion, Sec. 4.2 defines RSA1_5 only for "encrypting a JWE CEK" while your draft in Sec. 1.3 says that both "none" and "RSA1_5" are deprecated for both JWE and JWS.

 

I will reword this to clarify that “none” is deprecated for JWS and RSA1_5 for JWE. https://github.com/NeilMadden/jose-deprecate-none-rsa1_5/issues/2



  •  
  • I think the core sentence of this draft is "Application developers SHOULD disable support for these algorithms by default." And IMO it only has a chance of being effective if you change it to a MUST.

 

Yes, I agree. Will strength this to MUST.  https://github.com/NeilMadden/jose-deprecate-none-rsa1_5/issues/3



  •  
  • Going one sentence earlier, "JOSE library developers SHOULD deprecate support for these algorithms and commit to a timeline for removal." I think this sentence is meaningless because the word "deprecate" is not well defined by itself, and because nobody is going to send a timeline to the Protocol Police [RFC8962].

 

 

I’m not sure I follow why “deprecate” is not well defined? It is a widely used term in software engineering. I would think most library maintainers would be aware of this term. See eg https://en.wikipedia.org/wiki/Deprecation.



  •  
  • As a secdir reviewer I would have screamed at the current Security Considerations: "No security issues are introduced by this specification." If we need boilerplate text here - and we do - how about "this entire document is concerned with security, since the security of JOSE implementations directly affects the security of systems that include them (see for example the long list of CVEs in Sec. 1.1)."

 

Sure, I can change that. IMO both statements are equivalent. As you say, it’s boilerplate that adds no real value for this kind of RFC.



  •  
  • "standard security goal of authenticated encryption with associated data (AEAD)" - can you provide a reference? Otherwise this is too informal.

 

 

— Neil

 

_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to