Brian's comment - WGLC - alg:none

[yaronf]

Yaron: Adding to Mike’s response: the BCP, already in the published RFC8725, includes a SHOULD NOT for RSA-PKCS1 v1.5. And it was published 4 years before the “deprecate” draft.

Brian: Yes and even back in 2020ish the original RFC8725 probably should have been stronger about discouraging RSAES-PKCS1-v1_5.

My rationale for suggesting a reference to the "deprecate" draft, however, was primarily about wanting to see proper and accountable guidance regarding the treatment of "alg":"none", which I believe is long overdue. The "deprecate" draft was well ahead of the RFC8725bis draft in the document lifecycle when that suggestion was made. I don't believe the cited "precedent" around RFC9700 is really applicable to this case anyway. And even if the "deprecate" draft continues to be held up unecessarly, an informative downref would be totally reasonable.

I did say here that I believe "alg":"none" has "caused immeasurable and irreparable harm" but that's maybe too defeatist. I do think there's still some value to be found in work that endeavors to fix past mistakes. The RFC8725bis draft should take the opportunity to try.

CC: @bc-pi

[selfissued]

Per the mailing list discussion on this topic:

There’s precedent in OAuth for not holding up publishing a BCP because other developments may update the BCP later. In particular, we decided not to hold the OAuth Security BCP [RFC 9700] until we’d addressed already known vulnerabilities, including the one being addressed in rfc7523bis. Our logic was that it is better to publish the BCP in a timely fashion to get a set of useful information out to people and that the BCP will be updated when the mitigations for additional vulnerabilities are settled.

I'll note that RFC 9700 does not include an informative reference to rfc8725bis, even though rfc8725bis documents an actionable security vulnerability and a proposed best practice for preventing it. Both were known before draft-ietf-oauth-security-topics became RFC 9700. It was thought to be better to publish the set of recommendations already in the draft and then update the BCP as new recommendations became final. I believe that's the right course to follow here too. BCPs are meant to be updated, if and when new best current practices are developed.

As for "proper and accountable guidance regarding the treatment of "alg":"none"", I'll note that RFC 8725 already provided strong and actionable guidance specifically about "alg":"none":

JWT libraries SHOULD NOT consume JWTs using "none" unless explicitly requested by the caller.

So when the existing BCP guidance is followed, unless the recipient explicitly says that it wants to consume tokens using "alg":"none", misuse is already impossible.

[yaronf]

@bc-pi Is there a change you're proposing to our existing normative guidance,

JWT libraries SHOULD NOT consume JWTs using "none" unless explicitly requested by the caller.

[bc-pi]

@bc-pi Is there a change you're proposing to our existing normative guidance,

JWT libraries SHOULD NOT consume JWTs using "none" unless explicitly requested by the caller.

Yes. Make it stronger. Reference https://datatracker.ietf.org/doc/draft-ietf-jose-deprecate-none-rsa15/. And change the tone of the text to acknowledge that "alg":"none" as the specification design mistake that it was and stop putting the blame on implementations.