Thank you Dan for a very thorough review. Since everybody’s busy ahead of IETF week, I just piled everything into a GitHub issue for now: https://github.com/yaronf/draft-sheffer-oauth-rfc8725bis/issues/14 Best, Yaron From: Dan Moore <d...@fusionauth.io> Hi Yaron, Had some comments and formatting suggestions. I also found a broken link. Overall I found this a great summary of the JWT best practices I've seen in the wild and look forward to referring people to this doc. In https://www.ietf.org/archive/id/draft-sheffer-oauth-rfc8725bis-01.html#name-weak-symmetric-keys perhaps you want to mention this open source project which cracks JWTs signed with a weak HMAC key: https://github.com/brendan-rius/c-jwt-cracker to "However verifiers don't always check that the received JWT is a JWS (a signed JWT) as opposed to a JWE (a JWT with encrypted structure)." A JWS is by definition signed, just as a JWE is by definition encrypted, so I thought this was clearer. "Many encryption algorithms leak information about the length of the plaintext, with a varying amount of leakage depending on the algorithm and mode of operation." to "Many encryption algorithms leak information about the length of the plaintext, with a varying amount of leakage depending on the algorithm and mode of operation. JWEs are vulnerable to this leakage." Alternatively you could add other language to make it clear this attack is applicable to JWEs, not JWTs in general, just as is done in https://www.ietf.org/archive/id/draft-sheffer-oauth-rfc8725bis-01.html#section-2.12 . I suppose you could even change the section header to "JWE Plaintext Leakage through Analysis of Ciphertext Length". In general there are a few security issues that are related to encryption and therefore only affect JWEs. Is the attack outlined here https://www.ietf.org/archive/id/draft-sheffer-oauth-rfc8725bis-01.html#section-2.5 the same as
To "As JWTs are used by more protocols in diverse ways, it becomes increasingly important to prevent JWT tokens that have been issued for one purpose being used for another." Just think it reads cleaner.
This makes it a complete sentence. In https://www.ietf.org/archive/id/draft-sheffer-oauth-rfc8725bis-01.html#section-3.2 you quote the RFC which mentions SHOULD but then you follow it up with MUST. I find that confusing. I'd remove the first paragraph or at least this sentence: "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." because then you remove the SHOULD/MUST confusion I had. to "JWTs using "none" are often used in application contexts in which the content is optionally signed. The URL-safe claims representation and processing in this context can be the same in both the signed and unsigned cases." to "Libraries MUST allow the verifier to distinguish between signed JWTs (JWSes) and encrypted JWTs (JWEs). This allows verifiers to easily establish a policy of only accepting signed JWTs." I found the terms JWS-signed and JWT-encrypted confusing. They felt internally redundant (a JWS is always signed, for example). In https://www.ietf.org/archive/id/draft-sheffer-oauth-rfc8725bis-01.html#section-3.6 I wondered if it made sense to mention JWEs here? Maybe change "Compression of data SHOULD NOT be done before encryption, because such compressed data often reveals information about the plaintext." to "Compression of data SHOULD NOT be used when creating a JWE, because such compressed data often reveals information about the plaintext." This distinguishes between JWS and JWE, where the latter is the only one this recommendation applies to. In https://www.ietf.org/archive/id/draft-sheffer-oauth-rfc8725bis-01.html#section-3.7 I'd change to "Implementations and applications MUST do this and not use or allow the use of other Unicode encodings for these purposes." "If the same issuer can issue JWTs that are intended for use by more than one relying party or application, or may in the future," "or was substituted by an attacker at an unintended party." to "or was substituted by an attacker." I'm not sure what the "unintended party" phrase adds. "In such cases, the relying party or application MUST validate the audience value, and if the audience value is not present or not associated with the recipient, it MUST reject the JWT." "Per the definition of "typ" in Section 4.1.9 of [RFC7515], it is RECOMMENDED that the "application/" prefix be omitted from the "typ" value. Therefore, for example, the "typ" value used to explicitly include a type for a SET SHOULD be "secevent+jwt". When explicit typing is employed for a JWT, it is RECOMMENDED that a media type name of the format "application/example+jwt" be used, where "example" is replaced by the identifier for the specific kind of JWT." to "If more than one kind of JWT can be issued by the same issuer, the validation rules for those JWTs MUST be written such that they are mutually exclusive, rejecting JWTs of the wrong kind. to "[OWASP-Password-Storage] states a specific iteration count (600,000 at time of publishing) is required when using HMAC-SHA-256 to achieve FIPS-140 compliance. Rejecting inputs with a p2c (PBES2 Count) value larger than double the recommended OWASP value is RECOMMENDED." Thanks, Dan On Fri, May 23, 2025 at 4:18 AM Yaron Sheffer <yaronf.i...@gmail.com> wrote:
|
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
