ietf
[Top] [All Lists]

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

2014-09-22 10:28:09
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 <ietf(_at_)augustcellars(_dot_)com> 
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:ve7jtb(_at_)ve7jtb(_dot_)com] 
Sent: Saturday, September 20, 2014 3:55 AM
To: Jim Schaad
Cc: ietf(_at_)ietf(_dot_)org; secdir(_at_)ietf(_dot_)org; Richard Barnes; 
Tero Kivinen; Michael Jones; IESG; jose(_at_)ietf(_dot_)org; 
draft-ietf-jose-json-web-signature(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
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 <ietf(_at_)augustcellars(_dot_)com> 
wrote:


 
 
From: jose [mailto:jose-bounces(_at_)ietf(_dot_)org] On Behalf Of John Bradley
Sent: Friday, September 19, 2014 7:17 PM
To: Jim Schaad
Cc: ietf(_at_)ietf(_dot_)org; secdir(_at_)ietf(_dot_)org; Richard Barnes; 
Tero Kivinen; Michael Jones; IESG; jose(_at_)ietf(_dot_)org; 
draft-ietf-jose-json-web-signature(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
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 <ietf(_at_)augustcellars(_dot_)com> 
wrote:



 
 
From: Richard Barnes [mailto:rlb(_at_)ipv(_dot_)sx] 
Sent: Friday, September 19, 2014 2:32 PM
To: Mike Jones
Cc: Tero Kivinen; iesg(_at_)ietf(_dot_)org; secdir(_at_)ietf(_dot_)org; 
ietf(_at_)ietf(_dot_)org; 
draft-ietf-jose-json-web-signature(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org;jose(_at_)ietf(_dot_)org
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 
<Michael(_dot_)Jones(_at_)microsoft(_dot_)com> 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:rlb(_at_)ipv(_dot_)sx] 
Sent: Wednesday, September 17, 2014 6:24 AM
To: Tero Kivinen
Cc: Mike Jones; iesg(_at_)ietf(_dot_)org; secdir(_at_)ietf(_dot_)org; 
ietf(_at_)ietf(_dot_)org; 
draft-ietf-jose-json-web-signature(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org;jose(_at_)ietf(_dot_)org
Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31
 


On Wednesday, September 17, 2014, Tero Kivinen <kivinen(_at_)iki(_dot_)fi> 
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?
 
--
kivinen(_at_)iki(_dot_)fi
 
_______________________________________________
jose mailing list
jose(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/jose

Attachment: smime.p7s
Description: S/MIME cryptographic signature

<Prev in Thread] Current Thread [Next in Thread>