The datatracker is closed now until after IETF 119 (which I am also unable to attend), but I have created a draft for deprecating these algorithms that I intend to submit when it re-opens.
Working draft: https://neilmadden.github.io/jose-deprecate-none-rsa1_5/draft-madden-jose-deprecate-none-rsa15.html <https://neilmadden.github.io/jose-deprecate-none-rsa1_5/draft-madden-jose-deprecate-none-rsa15.html> Git repo: https://github.com/NeilMadden/jose-deprecate-none-rsa1_5 <https://github.com/NeilMadden/jose-deprecate-none-rsa1_5> -- Neil > On 5 Mar 2024, at 15:56, Neil Madden <[email protected]> wrote: > > 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 > <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf> > (see table 5 on page 15) > > Thoughts? > > -- Neil
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
