On Sun, Sep 21, 2014 at 10:10 PM, Jim Schaad <[email protected]> wrote:
> > > > > *From:* jose [mailto:[email protected]] *On Behalf Of *Richard Barnes > *Sent:* Sunday, September 21, 2014 5:32 PM > *To:* John Bradley > *Cc:* [email protected]; secdir; Jim Schaad; Tero Kivinen; Michael Jones; > IESG; [email protected]; [email protected] > *Subject:* Re: [jose] Secdir review of > draft-ietf-jose-json-web-signature-31 > > > > I think I may have erred by trying to write a treatise on which algorithms > are vulnerable :) Here's some updated text, trying to be more concise. > > Jim: Your points about SHA-256 vs. SHA-512/256 and SHA-256 vs. SHA-3 don't > really apply, since JOSE hasn't defined algorithm identifiers for > SHA-512/256 or SHA-3. > > > > [JLS] Richard – are you planning to update this text when (not if) they > are defined? If not then this is still part of the problem even if > currently not constrained. The same could also be said to be not a problem > for all of the ECDSA algorithms since there is only one hash defined of any > given length. (I will ignore the really fun problem for DSA and ECDSA > where there is a modulus operation that occurs on the hash value thus > creating collisions within the same hash function and making matching of > hash function lengths and key lengths of primary importance.) However, as > these will almost certainly be defined in the future, they merit inclusion > in the potential problems. I believe that this should be included in the > discussion as it is much easier to do than to break the mask function of > RSA. (Breaking the same hash function twice is very non-trival, having two > hash functions that produce the same length hash is much easier.) > Is the phrase "Obviously, if other algorithms are added, then they may introduce new risks" insufficient? --Richard > > """ > # Signature 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 he actually has not. These attacks have been discussed in detail in > the context of CMS {{RFC 6211}}. The risk arises when all of the following > are true: > > > * Verifiers of a signature support multiple algorithms of different > strengths > > * Given an existing signature, an attacker can find another payload that > produces the same signature value with a weaker algorithm > > * In particular, the payload crafted by the attacker is valid in a given > application-layer 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 results in the same signature with > SHA-256 as the signature with SHA-384 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 using JOSE to mitigate algorithm > substitution attacks > > The simplest mitigation is to not accept signatures using vulnerable > algorithms: Algorithm substitution attacks do not arise for all signature > algorithms. The only algorithms defined in JWA > {{I-D.ietf-jose-json-web-algorithms}} that may be vulnerable to algorithm > substitution attacks is RSA-PSS ("PS256", etc.). An implementation that > does not support RSA-PSS is not vulnerable to algorithm substitution > attacks. (Obviously, if other algorithms are added, then they may > introduce new risks.) > > In addition, substitution attacks are only feasible if an attacker can > compute pre-images for the weakest hash function accepted by the > recipient. All JOSE algorithms use SHA-2 hashes, for which there are no > known pre-image attacks as of this writing. Until there begin to be > attacks against SHA-2 hashes, even a JOSE implementation that supports PSS > is safe from substitution attacks. > > > > Without restricting algorithms, there are also mitigations at the JOSE and > application layer: At the level of JOSE, an application could require that > the "alg" parameter be carried in the protected header. (This is the > approach taken by RFC 6211.) The application could also include a field > reflecting the algorithm in the application payload, and require that it be > matched with the "alg" parameter during verification. (This is the approach > taken by PKIX {{RFC5280}}.) > > > > Of these mitigations, the only sure solution is the first, not to accept > vulnerable algorithms. Signing over the "alg" parameter (directly or > indirectly) only makes the attacker's work more difficult, by requiring > that the bogus payload also contain bogus information about the signing > algorithm. They do not prevent attack by a sufficiently powerful attacker. > """ >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
