OK but HMAC is not a signature so that won't get you very far. If I am the attacker and have a collision based on the weaker hash and you accept that why would I bother with changing the Hash alg?
I still see changing the hash alg as part of a digital digital signature as different from doing the same thing with the hash alg of a HMAC integrity protected message. John B. On Sep 20, 2014, at 12:45 PM, Jim Schaad <[email protected]> wrote: > No, the attack would run as follows: > > 1. I send you a message which is hashed > 2. You send back a message which includes the signature in your hash > 3. I take the other message with the bad signature to court and your > signature on the hash confirming you received it. > > Jim > > > From: John Bradley [mailto:[email protected]] > Sent: Saturday, September 20, 2014 3:55 AM > To: Jim Schaad > Cc: [email protected]; [email protected]; Richard Barnes; Tero Kivinen; Michael > Jones; IESG; [email protected]; > [email protected] > Subject: Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31 > > Hi Jim, > > I think I am missing something. > > If the sender is the attacker and has the mac key, then they can integrity > protect any plaintext they like with any hash that is supported.. > > This seems more like the sender wants to use a different hash than the > receiver prefers situation. > > That seems to me like a different security concern than an attacker taking a > existing JWS and using a downgrade on the alg parameter to substitute a less > collision resistant hash, in order to substitute a plain text (envelope and > body in the Compact case) that has the same hash value as that encrypted by > the RSA/EC key. > > Thanks > John B. > > On Sep 19, 2014, at 11:34 PM, Jim Schaad <[email protected]> wrote: > > > > > From: jose [mailto:[email protected]] On Behalf Of John Bradley > Sent: Friday, September 19, 2014 7:17 PM > To: Jim Schaad > Cc: [email protected]; [email protected]; Richard Barnes; Tero Kivinen; Michael > Jones; IESG; [email protected]; > [email protected] > Subject: Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31 > > For HMAC changing the hash from SHA3 256 to SHA2 256 doesn't really get the > attacker much as they still don't know the key to be able to create a > appropriate fake plaintext. > So simply knowing a value that creates a collision is not sufficient for an > attack. > > [JLS] remember that the attacker can be the sender of the message, in this > case the key is known to the attacker. > > I interpreted Mike's comment on PKCS#1 as being that the signature needs to > be verified by the algorithm specified in the "alg" parameter. That is not > to say that if in the case of PKCS#1 padding if the OID is not consistent > with the value of "alg" that wouldn't be an error. I think that would be a > invalid JWS. I do think that should be made clear. > > With PSS if the key is the same length it is true that you are going to be > vulnerable to collisions over the plaintext based on the weakest hash you can > get the receiver to accept. > This is not a issue unique to JOSE in any way. One would be tempted to rule > out SHA1 now but it is differentiated by it's key length, so can't be > downgraded to from SHA2. > > John B. > > > On Sep 19, 2014, at 7:25 PM, Jim Schaad <[email protected]> wrote: > > > > > > From: Richard Barnes [mailto:[email protected]] > Sent: Friday, September 19, 2014 2:32 PM > To: Mike Jones > Cc: Tero Kivinen; [email protected]; [email protected]; [email protected]; > [email protected];[email protected] > Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31 > > """ > # 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 "PS1" and "PS256" > as "alg" values, and a signer creates a signature using "PS256". If the > attacker can craft a payload that has the same SHA-1 digest has as the > SHA-256 digest of the legitimate payload, then the "PS1" signature over the > bogus payload will be the same as the "PS256" signature over the legitimate > payload. > > There are several ways for an application using JOSE to mitigate algorithm > substitution attacks: > > * Don't accept signatures using vulnerable algorithms: Algorithm substitution > attacks do not arise for all signature algorithms. > * Signatures using RSA PKCS#1 v1.5 ("RS1", "RS256", etc.) are not subject > to substitution attacks because the signature value itself encodes the hash > function used. > * Signatures with HMAC algorithms ("HS1", "HS256", etc.) cannot be > substituted because the signature values have different lengths Likewise for > signatures with ECDSA algorithms ("ES256", "ES384", etc.). > > [JLS] This is not a true statement. If you support both SHA256 and > SHA512/256 then the signature values have the same length. This will also be > an issue if you support both the SHA2 and the SHA3 algorithm sets as they > have results of the same length. > > * The only algorithms defined in JWA {{I-D.ietf-jose-json-web-algorithms}} > that is vulnerable to algorithm substitution attacks is RSA-PSS ("PS1", > "PS256", etc.). An implementation that does not support RSA-PSS is not > vulnerable to algorithm substitution attacks. > > [JLS] ECDSA is open to this attack if you support both SHA256 and SHA512/256 > the hash lengths are the same. This will also be an issue if you support > both the SHA2 and the SHA3 algorithm sets as they have results of the same > length. > > * Require that the "alg" parameter be carried in the protected header. (This > is the approach taken by RFC 6211.) > > * 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}}.) > > [JLS] RSA-PKCS#1.5 is open to this attack if the suggestion of Mike in a > message prior to this is put into the text. That is to allow for the hash > inside of the signature and that outside of the signature to differ in value > because you only enforce one of the two values. > > Of these mitigations, the only sure solution is the first. 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. > """ > > On Fri, Sep 19, 2014 at 2:49 PM, Mike Jones <[email protected]> > wrote: > I would appreciate it if you would write a draft of the proposed security > considerations text, Richard. Perhaps title the section “Unsecured Algorithm > Values”. > > Thanks! > -- Mike > > From: Richard Barnes [mailto:[email protected]] > Sent: Wednesday, September 17, 2014 6:24 AM > To: Tero Kivinen > Cc: Mike Jones; [email protected]; [email protected]; [email protected]; > [email protected];[email protected] > Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31 > > > > On Wednesday, September 17, 2014, Tero Kivinen <[email protected]> wrote: > Richard Barnes writes: > > Perhaps, but is there benefits for leaving the alg without protection? > > > > Simplicity (if you omit protected headers altogether), and > > compatibility with other signed things. In the sense that you could > > transform one of them into a JWS without re-signing. This would > > apply, for example, to an X.509 certificate -- just parse the outer > > SEQUENCE, and re-assemble into a JWS with the tbsCertificate as > > payload. Same security properties that X.509 already has. > > Ok, having this kind of information somewhere in the draft would help > to understand the reason. Also having text explaining that is > possible, and that the security properties of this option (i.e. no > problem with PKCS#1, etc... the text you had in the other email). > > > It's also completely unnecessary for PKCS#1 signatures, which are > > the dominant use case today. > > I agree. > > > In general, I'm opposed to protocols baking in more > > application-specific logic than they need to. The point of JOSE is > > to describe the cryptographic operation that was performed, and > > carry the relevant bits around. Its job is not to fix all the > > weaknesses that every algorithm has. > > Yes, but this property might have security issues, so they should be > covered by the security considerations section. > > I'm perfectly happy to have it documented in the Security Considerations. > > Mike: Should I generate some text, or do you want to take a stab? > > -- > [email protected] > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
