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

Mike Jones <> Tue, 23 September 2014 01:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 91D401A1BF6; Mon, 22 Sep 2014 18:29:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wJO1aoa-mVAh; Mon, 22 Sep 2014 18:29:47 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fc10::719]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DF3401A1B32; Mon, 22 Sep 2014 18:29:46 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1034.13; Tue, 23 Sep 2014 01:29:18 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1034.13; Tue, 23 Sep 2014 01:29:16 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1034.13 via Frontend Transport; Tue, 23 Sep 2014 01:29:15 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Tue, 23 Sep 2014 01:29:15 +0000
Received: from ([]) by ([]) with mapi id 14.03.0195.002; Tue, 23 Sep 2014 01:28:36 +0000
From: Mike Jones <>
To: Richard Barnes <>, Tero Kivinen <>
Thread-Topic: [jose] Secdir review of draft-ietf-jose-json-web-signature-31
Date: Tue, 23 Sep 2014 01:28:36 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <03a601cfd460$f8d71d70$ea855850$> <> <03c701cfd483$d1cf45e0$756dd1a0$> <> <043a01cfd4f2$3df75ff0$b9e61fd0$> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BA6A6FATK5EX14MBXC286r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(199003)(93886004)(44976005)(92726001)(16236675004)(31966008)(19580395003)(19300405004)(85306004)(86362001)(83322001)(6806004)(2656002)(10300001)(120916001)(76482002)(87936001)(19625215002)(92566001)(84326002)(84676001)(106116001)(106466001)(81156004)(95666004)(20776003)(80022003)(90102001)(74662003)(77096002)(85806002)(54356999)(66066001)(55846006)(97736003)(85852003)(86612001)(76176999)(64706001)(230783001)(107046002)(69596002)(26826002)(104016003)(33656002)(46102003)(15202345003)(21056001)(81542003)(79102003)(81342003)(512874002)(74502003)(77982003)(83072002)(71186001)(15975445006)(68736004)(99396002)(4396001)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB1210;; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-Microsoft-Antispam: UriScan:;UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB1210;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0343AC1D30
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Authentication-Results: spf=pass (sender IP is;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB1180;
Cc: "" <>, secdir <>, Jim Schaad <>, IESG <>, "" <>, John Bradley <>, "" <>
Subject: Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Sep 2014 01:29:49 -0000

My current editor’s draft contains the following security considerations subsection, which is derived from Richard’s proposed text.  I’m sending it now for working group review, with the intent to publish updated drafts addressing all the Gen-ART and secdir comments received, possibly as early as sometime tomorrow.

This subsection is over three times the size of any of the other security considerations subsections.  It’s my hope, as an editor, that people will suggest ways to drastically shorten it, while retaining understandable and actionable content, before I publish an updated draft.

I obviously hope that people will also review it for correctness.

                                                                Thank you,
                                                                -- Mike

10.7.  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 it has not. These attacks have been discussed in detail in the context of CMS [RFC6211]. The risk arises when all of the following are true:
·         Verifiers of a signature support multiple algorithms.
·         Given an existing signature, an attacker can find another payload that produces the same signature value with a different algorithm.
·         The payload crafted by the attacker is valid in the application 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 has the same SHA-256 digest as the SHA-384 digest 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 to mitigate algorithm substitution attacks:
·         Don't accept signatures using algorithms vulnerable to substitution attacks. Algorithm substitution attacks are not possible for all signature algorithms. The only algorithms defined in JWA [JWA] that may be vulnerable to algorithm substitution attacks are the RSASSA-PSS (PS256, PS384, etc.) algorithms. An implementation that does not support RSASSA-PSS or other vulnerable algorithms is not susceptible to algorithm substitution attacks. Substitution attacks are only feasible if an attacker can compute pre-images for a hash function accepted by the recipient. All JWA-defined algorithms use SHA-2 hashes, for which there are no known pre-image attacks, as of the time of this writing. Until there are attacks against SHA-2 hashes, even implementations that support RSASSA-PSS are not susceptible to substitution attacks.
·         Require that the alg Header Parameter be carried in the protected header. (This is always the case when using the JWS Compact Serialization and is the approach taken by CMS [RFC6211].)
·         Include a field containing the algorithm in the application payload, and require that it be matched with the alg Header Parameter during verification. (This is the approach taken by PKIX [RFC5280].)