I have made changes to the GitHub draft (https://neilmadden.github.io/jose-deprecate-none-rsa1_5/draft-ietf-jose-deprecate-none-rsa15.html) as discussed. I’ve also slightly reworded the guidance around deprecation to now say simply "JOSE library developers should deprecate support for these algorithms.” - that is changing SHOULD to should as it’s an informal suggestion, not something enforceable, and dropping the wording around “commit to a timeline for removal”.
I’ll wait to see if there is any more feedback after Bangkok before pushing a new version to Datatracker. Best wishes, Neil > On 24 Mar 2025, at 06:55, Yaron Sheffer <[email protected]> wrote: > > 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. > > Will do - raised > https://github.com/NeilMadden/jose-deprecate-none-rsa1_5/issues/1 > > > > > 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. > > Will do - https://github.com/NeilMadden/jose-deprecate-none-rsa1_5/issues/4 > > — Neil
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
