Thanks for caring about the security of JOSE, Neil. I'll take one more shot at this, with replies inline...
-----Original Message----- From: Neil Madden <[email protected]> Sent: Wednesday, March 6, 2024 12:10 AM To: Michael Jones <[email protected]> Cc: Manu Sporny <[email protected]>; JOSE WG <[email protected]> Subject: Re: [jose] Deprecation of legacy algorithms >>On 5 Mar 2024, at 23:24, Michael Jones <[email protected]> wrote: >> >> While this is been said many times before, it seems that it's time to say >> it again. The last point in the Message Signature or MAC Validation section >> at https://www.rfc-editor.org/rfc/rfc7515.html#section-5.2 is: >> >> "Finally, note that it is an application decision which algorithms may be >> used in a given context. Even if a JWS can be successfully validated, >> unless the algorithm(s) used in the JWS are acceptable to the application, >> it SHOULD consider the JWS to be invalid." >> "alg":"none" can only cause a problem if the application fails to validate >> whether the algorithms used are appropriate for use by the application in >> that context. The need to validate whether "alg":"none" is appropriate is >> no different than the need to validate whether use of RSA1_5 is appropriate. >There are three big differences between these cases: >* alg:none provides no security properties, whereas all of the other >algorithms do Nor was it ever intended to - hence being called "none". :-) It's for use where security properties are unnecessary. >* alg:none doesn’t require a key, so will not be caught by checks on key >type/algorithm It's caught by the algorithm check when the recipient inspects the "alg" header parameter value. >* alg:none purports to be a signature algorithm, but isn’t. Many developers >don’t even know it exists. It's fine that developers don't know it exists. If they don't know about it, it won't be in the list of acceptable "alg" values when they do the check, and therefore it will be rejected. >For example, OIDC says ID Tokens MUST be signed, which would imply to most >people that they are always integrity protected. But somehow “none” is a valid >signature algorithm. Actually, I already cited the Connect spec text saying that "alg":"none" can be used when requested by the RP and the ID Token is sent over TLS from the Token Endpoint. >> An ID Token using "alg":"none" sent over a TLS connect is fine, because TLS >> makes it tamper-proof. >This not true. It guarantees delivery of the issued ID Token without changes from the OP to the RP. >> As it says at https://openid.net/specs/openid-connect-core-1_0.html#IDToken: >> >> "ID Tokens MUST NOT use "none" as the "alg" value unless the Response Type >> used returns no ID Token from the Authorization Endpoint (such as when using >> the Authorization Code Flow) and the Client explicitly requested the use of >> "none" at Registration time." >> >> The context where the algorithm is used matters. In the above usage, >> "alg":"none" is safe and appropriate. >Sure, but just returning some JSON would also be fine. What benefit does it >gain? It gains the benefit that all ID Tokens have fields base64url-encoded in the same manner and that they are all URL safe. JSON is not URL safe. >> The issues that have happened only happened in applications that didn't >> implement the algorithm appropriateness check in Section 5.2. If they're >> not doing it for "none", they probably aren't doing it for any algorithms, >> and so the application would still be vulnerable to using obsolete >> algorithms even if we deprecated "none". >> >> Fix the broken applications. Don't remove essential functionality that's >> been a standard for nearly a decade and has been in production use longer >> than that. >This is the same reasoning as “C is a safe language, you’re just using it >wrong”. We can’t keep having multiple critical vulnerabilities per year due to >a feature that actually almost nobody intentionally uses. Again, if you don't check the "alg" value, critical vulnerabilities will occur regardless. I view the presence of "none" as a not-so-subtle reminder to do just that. :-) >As a counterpoint, while I was still there ForgeRock disabled “none” by >default. As far as I’m aware nobody ever complained or even noticed. I’ve >never met anyone who wants unsecured ID Tokens. The last I knew, Deutsche Telekom uses "alg":"none" in their ID Tokens. In fact, the ability to do so was added to OpenID Connect when Torsten Lodderstedt was identity lead there. He wanted DT RPs to not need cryptographic code (other than the TLS stacks beneath them). It worked fine. Finally, I know of other JOSE libraries that make you jump through special hoops to use "none" - somehow indicating that "I know what I'm doing" in the API. That's fine and I support that. That's different than deprecating "none" in the algorithms registry, which would be an overly blunt instrument trying to take away useful and used functionality. >— Neil Best wishes, -- Mike _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
