Re: [secdir] [jose] Secdir review of draft-ietf-jose-json-web-signature-31

[Mike Jones <[e-mail]>]

My current editor’s draft contains the following security considerations subsection, which is derived from Richard’s proposed text.  I’m sending it now for working group review, with the intent to publish updated drafts addressing all the Gen-ART and secdir comments received, possibly as early as sometime tomorrow.

This subsection is over three times the size of any of the other security considerations subsections.  It’s my hope, as an editor, that people will suggest ways to drastically shorten it, while retaining understandable and actionable content, before I publish an updated draft.

I obviously hope that people will also review it for correctness.

                                                                Thank you,
                                                                -- Mike

10.7.  Algorithm Protection

In some usages of JWS, there is a risk of algorithm substitution attacks, in which an attacker can use an existing signature value with a different signature algorithm to make it appear that a signer has signed something that it has not. These attacks have been discussed in detail in the context of CMS [RFC6211]. The risk arises when all of the following are true:
·         Verifiers of a signature support multiple algorithms.
·         Given an existing signature, an attacker can find another payload that produces the same signature value with a different algorithm.
·         The payload crafted by the attacker is valid in the application context.

For example, suppose a verifier is willing to accept both PS256 and PS384 as alg values, and a signer creates a signature using PS256. If the attacker can craft a payload that has the same SHA-256 digest as the SHA-384 digest of the legitimate payload, then the PS256 signature over the bogus payload will be the same as the PS384 signature over the legitimate payload.

There are several ways for an application to mitigate algorithm substitution attacks:
·         Don't accept signatures using algorithms vulnerable to substitution attacks. Algorithm substitution attacks are not possible for all signature algorithms. The only algorithms defined in JWA [JWA] that may be vulnerable to algorithm substitution attacks are the RSASSA-PSS (PS256, PS384, etc.) algorithms. An implementation that does not support RSASSA-PSS or other vulnerable algorithms is not susceptible to algorithm substitution attacks. Substitution attacks are only feasible if an attacker can compute pre-images for a hash function accepted by the recipient. All JWA-defined algorithms use SHA-2 hashes, for which there are no known pre-image attacks, as of the time of this writing. Until there are attacks against SHA-2 hashes, even implementations that support RSASSA-PSS are not susceptible to substitution attacks.
·         Require that the alg Header Parameter be carried in the protected header. (This is always the case when using the JWS Compact Serialization and is the approach taken by CMS [RFC6211].)
·         Include a field containing the algorithm in the application payload, and require that it be matched with the alg Header Parameter during verification. (This is the approach taken by PKIX [RFC5280].)