Re: [jose] Deprecation of legacy algorithms

[Ilari Liusvaara <[e-mail]>]

On Tue, Mar 05, 2024 at 03:56:30PM +0000, Neil Madden wrote:
> 
> 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]. 

That algorithm is marked as recommended???

It is essentially impossible to safely decrypt RSA PKCS#1 v1.5 online
(as part of any realtime protocol). The only reason TLS 1.2 could get
away with it is very TLS-specific hacks (which make the problem much
easier). Still, there are very few if any implementations that have not
had vulnerability here.

 
> 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.
> 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.

Trying to verify alg=none signature MUST unconditionally fail.

Library doing anything else is a critical vulnerability. 


> 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.

Add all encryption algorithms in COSE MUST be authenticated (JOSE
already has stronger requirement of being AEAD).

And then change algorithms that are not (IIRC, there are six) to
"MUST NOT implement".




-Ilari