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

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