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

Also with PSS the attack is largely mitigated if the mask function uses the 
same hash as the message. http://tools.ietf.org/html/rfc3447#page-29

JWA sec 3.5  requires SHA2 MGF functions for SHA2 message hashes with the 
equivalent length.

If the same is done when SHA3 is added then I think PSS is not as susceptible 
to a substitution attack as it might look on the surface.

Sorry I just remembers that there was that mitigation for PSS.

John B.
On Sep 21, 2014, at 8:47 PM, John Bradley <ve7jtb(_at_)ve7jtb(_dot_)com> wrote:

> I like the general direction.
>
> One question,  wouldn't the recipient of a PSS signature detect the 
> substitution of SHA-284 with SHA-256 due to the different key length.
>
> I was under the perhaps mistaken impression that the key lengths needed to be 
> the same and just the alg different eg SHA3 and SHA2 keys of the same length.
>
> If that is the case we probably have not defined any algs currently that may 
> be subject to this.  That is not to say that we shouldn't warn people as new 
> algs are defined.
>
> John B.
>
>
> On Sep 21, 2014, at 8:32 PM, Richard Barnes <rlb(_at_)ipv(_dot_)sx> wrote:
>
> > 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.
> >
> > """
> > # 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.
> > """

smime.p7s
Description: S/MIME cryptographic signature