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

Richard Barnes <> Fri, 19 September 2014 21:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E80A11A854B for <>; Fri, 19 Sep 2014 14:32:30 -0700 (PDT)
X-Quarantine-ID: <1jah5gg_tLaI>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BANNED, message contains text/plain,.exe
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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 1jah5gg_tLaI for <>; Fri, 19 Sep 2014 14:32:29 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 58AC21A70FE for <>; Fri, 19 Sep 2014 14:32:26 -0700 (PDT)
Received: by with SMTP id q1so3961689lam.3 for <>; Fri, 19 Sep 2014 14:32:24 -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=mrIHpafWBfW4hKN5RgUsF/Bku+59bu6RQBO7CrlioD4=; b=Pm8rdswiBXLHqopFa7+scRvPCl6eEKnEkvsU3EBsMgmaDPkzLyjwAg1kw0gkwY6BC1 rqma7WToKv2hUj77VAUIBzvDHVU39v3GC0VYDNTrPJCvmuK3pfqRrR9mOc6p9sciPQt7 UDeVqX71pn2r0TwUqLW1L7qV+oBfBTPWowHoU57ctdBGztc+aaz7KJxu9CN8/GNzN3jS oMFkKqVeQCZpUI3VKCm6oI4JlTBvfLtQAwv5KFJsYQ9rOsr9scN/UyMeCCsm7VbUaQPA 2EyFmFH0HSvs9DlS7Yt2yduXBLc9RNhK/VFZBdiIrsU7JpLSLTivIyyq2apmtbngdxoD Yo3g==
X-Gm-Message-State: ALoCoQmURdKEKLodPHkoBve+a+oXLYZzyV38v/B7cIfLgIDmpe9G34pydTNzVP8fMvDUEYVHhevG
MIME-Version: 1.0
X-Received: by with SMTP id j1mr9154766laj.73.1411162344290; Fri, 19 Sep 2014 14:32:24 -0700 (PDT)
Received: by with HTTP; Fri, 19 Sep 2014 14:32:24 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Fri, 19 Sep 2014 17:32:24 -0400
Message-ID: <>
From: Richard Barnes <>
To: Mike Jones <>
Content-Type: multipart/alternative; boundary=089e0149338c408e92050371d62b
Cc: "" <>, "" <>, "" <>, "" <>, "" <>
Subject: Re: [secdir] 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: Fri, 19 Sep 2014 21:32:31 -0000

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

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

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

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

>  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 []
> *Sent:* Wednesday, September 17, 2014 6:24 AM
> *To:* Tero Kivinen
> *Cc:* Mike Jones;;;;
> *Subject:* Re: Secdir review of draft-ietf-jose-json-web-signature-31
> On Wednesday, September 17, 2014, Tero Kivinen <> 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?
> --