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

Tero Kivinen <> Mon, 22 September 2014 13:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D183E1A1ADB; Mon, 22 Sep 2014 06:27:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eZKYPKo6JQKW; Mon, 22 Sep 2014 06:27:06 -0700 (PDT)
Received: from ( [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A56071A1AC9; Mon, 22 Sep 2014 06:27:03 -0700 (PDT)
Received: from (localhost []) by (8.14.8/8.14.8) with ESMTP id s8MDQwTr026343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Sep 2014 16:26:58 +0300 (EEST)
Received: (from kivinen@localhost) by (8.14.8/8.14.8/Submit) id s8MDQun3023591; Mon, 22 Sep 2014 16:26:56 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Mon, 22 Sep 2014 16:26:56 +0300
From: Tero Kivinen <>
To: Richard Barnes <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <03a601cfd460$f8d71d70$ea855850$> <> <03c701cfd483$d1cf45e0$756dd1a0$> <> <043a01cfd4f2$3df75ff0$b9e61fd0$> <> <>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 15 min
X-Total-Time: 19 min
Cc: "" <>, secdir <>, Jim Schaad <>, 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 13:27:18 -0000

Richard Barnes writes:
> * Given an existing signature, an attacker can find another payload
> that produces the same signature value with a weaker algorithm

I think one of the major points is that hash algorithms try to make
sure that collisions are hard but ONLY INSIDE the same algorithm. I.e.
it is hard to find collisions for SHA-256. On the other hand nothing
is said how hard it is said to create SHA-1 hash that matches some
SHA-256-160 message. I.e. all the security analysis we have for
SHA-256 are worthless as they do not cover creating collision between
SHA-256 and SHA-1. I.e. SHA-256 was designed to be collision resistant
with SHA-256, but not with SHA-1. It might be secure, or it might not.

I think there are some papers talking about creating collisions
between MD5 and SHA-1, but those are done by analysing the hash
functions, i.e. not while designing the algorithms. I.e. this kind of
attacks were not major design criteria when algorithms were made.

I.e. most of the properties designed in to the hash functions are not
true anymore if we try to match two different algorithms against each

On the other hand I think that one of the design criteria for creating
SHA-2 family was that there is no collisions between different
algorithms in the same family.