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

Richard Barnes <> Mon, 22 September 2014 00:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 427D01A0395 for <>; Sun, 21 Sep 2014 17:32:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.723
X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Uc4Xo8prbyM8 for <>; Sun, 21 Sep 2014 17:32:07 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4065F1A039C for <>; Sun, 21 Sep 2014 17:32:02 -0700 (PDT)
Received: by with SMTP id l4so5784309lbv.2 for <>; Sun, 21 Sep 2014 17:32:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/lHru6Plxk5l0mB5uxM89nE2j1YSu2SzfH3Gfnb/jkg=; b=Bfah0IybQcpnfHU7AjmIWb4L5OSBlL9RMZRK1vxpLC5QFpoYP5utKC01mURZbozSD+ xZRwT2558Zcl78dfoKXCYgsdbjaHhJYq/RSHI7dG+Jeyw7NysfsLP5BYC4UlkKXm9T1y eTGAV+WmcjFomJA16cTvNlFkDzNbXZ7ZmqnXN+4Eyu1FVvMLhw7gMzuofJDbyyv3yvrl FfzfW/DlTo+Ic4zXvsJeLMNQpwYkhawrHozQJ6KMUypxD3FwMNQxKuCKp+2URQ1CV1/o rf2YNnpHZyq0Z1G6o3r5wuxh1VP4kCn05AEaobQJj+y0AGisJeRxvcMaWYkPE9e+tXfK bqqw==
X-Gm-Message-State: ALoCoQkMZabzzEDTzIc6yS3ORxpjChpsksLTG+hAThpDR9s19pTNrsJ9CQpnXtSMvMQwNcHQM0SS
MIME-Version: 1.0
X-Received: by with SMTP id x8mr21931287lax.18.1411345921192; Sun, 21 Sep 2014 17:32:01 -0700 (PDT)
Received: by with HTTP; Sun, 21 Sep 2014 17:32:01 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <03a601cfd460$f8d71d70$ea855850$> <> <03c701cfd483$d1cf45e0$756dd1a0$> <> <043a01cfd4f2$3df75ff0$b9e61fd0$> <>
Date: Sun, 21 Sep 2014 20:32:01 -0400
Message-ID: <>
From: Richard Barnes <>
To: John Bradley <>
Content-Type: multipart/alternative; boundary=089e0141a02049c41605039c9485
Cc: "" <>, secdir <>, Jim Schaad <>, Michael Jones <>, IESG <>, "" <>, "" <>
Subject: Re: [secdir] [jose] Secdir review of draft-ietf-jose-json-web-signature-31
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Sep 2014 00:32:09 -0000

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

* 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.