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