Re: [jose] Deprecation of legacy algorithms

Sorry – you’re right Brian.  I replied too fast.  I was thinking of something else.

In fact, we removed instances of RSA1_5 from the examples in OpenID Connect as part of the errata updates.

                                                                -- Mike

From: Brian Campbell <bcampbell@pingidentity.com>
Sent: Tuesday, March 5, 2024 9:40 AM
To: Michael Jones <michael_b_jones@hotmail.com>
Cc: Neil Madden <neil.e.madden@gmail.com>; JOSE WG <jose@ietf.org>
Subject: Re: [jose] Deprecation of legacy algorithms

The JWE RSA1_5 alg is not required for OpenID Connect as far as I know?

On Tue, Mar 5, 2024 at 9:39 AM Michael Jones <michael_b_jones@hotmail.com<mailto:michael_b_jones@hotmail.com>> wrote:
I would not support deprecation of either of these algorithms.  They are both required for OpenID Connect and are in extremely widespread use.

From: jose <jose-bounces@ietf.org<mailto:jose-bounces@ietf.org>> On Behalf Of Neil Madden
Sent: Tuesday, March 5, 2024 7:57 AM
To: JOSE WG <jose@ietf.org<mailto:jose@ietf.org>>
Subject: [jose] Deprecation of legacy algorithms

Hi all,

Leaving aside all the exciting work on shiny new algorithms to *add* to JOSE, I would like to raise the prospect of deprecating some existing algorithms that have passed their best. Before I start work on writing the drafts for these, I'd like to gauge if there is some support or this is likely to be wasted effort. The algorithms I think that should be deprecated are:

RSA1_5 - currently marked as Recommended- in the IANA registry. PKCS#1 v1.5 padding for encryption has been a source of repeated vulnerabilities over the years, and they keep cropping up. I believe the main reason this exists at all was to allow continued use of legacy hardware, in particular where FIPS approval was required. However, PKCS#1 v1.5 padding has been forbidden by FIPS (for encryption) since the end of this 2023 [1]. If someone is really stuck with a hardware device that only supports this encryption mode then they can use it to encrypt local files containing keys for other algorithms rather than using it directly.

none - I know this one is more controversial in some quarters, but alg=none has been responsible for a steady stream of serious security vulnerabilities, and even spawned its own website: https://www.howmanydayssinceajwtalgnonevuln.com<https://www.howmanydayssinceajwtalgnonevuln.com/>. I'm not sure there has actually been a year where this algorithm *hasn't* caused a vulnerability. I've yet to see a genuine use-case for it in the wild. The pain:gain ratio on this algorithm is extremely high.

I would also like to write a draft (either combined with the above or separate) that establishes some baseline security properties for future algorithm registrations:

* All signature algorithms MUST achieve unforgeability under chosen message attack (EUF-CMA).
* All encryption algorithms MUST achieve at least IND-CCA2.

[1]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf (see table 5 on page 15)

Thoughts?

-- Neil
_______________________________________________
jose mailing list
jose@ietf.org<mailto:jose@ietf.org>
https://www.ietf.org/mailman/listinfo/jose

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.