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

["Jim Schaad" <[e-mail]>]

 

 

From: Richard Barnes [mailto:[e-mail]] 
Sent: Friday, September 19, 2014 2:32 PM
To: Mike Jones
Cc: Tero Kivinen; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
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 <[e-mail]> 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:[e-mail]] 
Sent: Wednesday, September 17, 2014 6:24 AM
To: Tero Kivinen
Cc: Mike Jones; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31

 



On Wednesday, September 17, 2014, Tero Kivinen <[e-mail]> 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?

 

--
[e-mail]