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

Richard Barnes <> Mon, 22 September 2014 02:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8CC071A19EB for <>; Sun, 21 Sep 2014 19:21:49 -0700 (PDT)
X-Quarantine-ID: <Rq8fSRLDS2sz>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BANNED, message contains text/plain,.exe
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rq8fSRLDS2sz for <>; Sun, 21 Sep 2014 19:21:48 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 74CE61A19F4 for <>; Sun, 21 Sep 2014 19:21:45 -0700 (PDT)
Received: by with SMTP id 10so5281008lbg.24 for <>; Sun, 21 Sep 2014 19:21:43 -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=rRpnwyw/BIeuWzzbE4H+zMg21S73NRNISXYaRJsaoH0=; b=miqWKaXTbYvjuHihGWfysK+sMbFgutJrf8V5EsQR42yv6M1l3hov4ZIdQZ80TT+DS9 Uu37KYB3dn5DbeSFcmUBrmogh5DaMlTT3Pg98mmfH6OBfaQRKBBoaJv36ZzlWXWy8mJ7 P9v7oXS3WHODEQqSlGJzDoZ4vMJJwqJ65+nHH+DFyKEIDaWnXWithM4uQZijirOJ2clT FkDjW2b3f1hfWlgkTPO1sIPuBy6ZhBG8ZRqcR2ctmYsBerRRoPSF68xNnGx8a/brN730 i0D1IZ4biRHaiUOCWjG8yYj754Mce5LjpCBbfYbmVNHNno6aSKdiLZyzoslkVqjqDNJ0 wwzA==
X-Gm-Message-State: ALoCoQkYEzw83UM55nghzO72QExvqLbTLl0QhXUbBjg3tj96iBzaCUpD2F2gGMyAzjiAIEXvfqtQ
MIME-Version: 1.0
X-Received: by with SMTP id la5mr21297452lbc.2.1411352503674; Sun, 21 Sep 2014 19:21:43 -0700 (PDT)
Received: by with HTTP; Sun, 21 Sep 2014 19:21:43 -0700 (PDT)
In-Reply-To: <04fd01cfd60a$71d0cc80$55726580$>
References: <> <> <> <> <> <> <> <> <> <03a601cfd460$f8d71d70$ea855850$> <> <03c701cfd483$d1cf45e0$756dd1a0$> <> <043a01cfd4f2$3df75ff0$b9e61fd0$> <> <> <04fd01cfd60a$71d0cc80$55726580$>
Date: Sun, 21 Sep 2014 22:21:43 -0400
Message-ID: <>
From: Richard Barnes <>
To: Jim Schaad <>
Content-Type: multipart/alternative; boundary=001a11c3c178a27dcd05039e1c6d
Cc: "" <>, secdir <>, Michael Jones <>, IESG <>, "" <>, John Bradley <>, "" <>
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 02:21:49 -0000

On Sun, Sep 21, 2014 at 10:10 PM, Jim Schaad <> wrote:

> *From:* jose [] *On Behalf Of *Richard Barnes
> *Sent:* Sunday, September 21, 2014 5:32 PM
> *To:* John Bradley
> *Cc:*; secdir; Jim Schaad; Tero Kivinen; Michael Jones;
> IESG;;
> *Subject:* Re: [jose] Secdir review of
> draft-ietf-jose-json-web-signature-31
> 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.
> [JLS] Richard – are you planning to update this text when (not if) they
> are defined?  If not then this is still part of the problem even if
> currently not constrained.  The same could also be said to be not a problem
> for all of the ECDSA algorithms since there is only one hash defined of any
> given length.  (I will ignore the really fun problem for DSA and ECDSA
> where there is a modulus operation that occurs on the hash value thus
> creating collisions within the same hash function and making matching of
> hash function lengths and key lengths of primary importance.)  However, as
> these will almost certainly be defined in the future, they merit inclusion
> in the potential problems.   I believe that this should be included in the
> discussion as it is much easier to do than to break the mask function of
> RSA.  (Breaking the same hash function twice is very non-trival, having two
> hash functions that produce the same length hash is much easier.)

Is the phrase "Obviously, if other algorithms are added, then they may
introduce new risks" insufficient?


> """
> # 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.
> """