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

Richard Barnes <rlb@ipv.sx> Mon, 22 September 2014 13:59 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94111A1AC2 for <jose@ietfa.amsl.com>; Mon, 22 Sep 2014 06:59:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49N0kt7pczHs for <jose@ietfa.amsl.com>; Mon, 22 Sep 2014 06:59:03 -0700 (PDT)
Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58BD1A1AE0 for <jose@ietf.org>; Mon, 22 Sep 2014 06:41:53 -0700 (PDT)
Received: by mail-lb0-f180.google.com with SMTP id b12so6648210lbj.25 for <jose@ietf.org>; Mon, 22 Sep 2014 06:41:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fRXw4mLXedJ2a98iMuZXPuhlfIJVlIZb3eoNdnEDVc4=; b=XMuMDXtsh/Pkmqtw1CLaACvMlM6gOa8vktv5JHxh87abFm4JoIF397kIVN1i8iGmhK 6EL6cXNnhEAl6kltgrBQwIVDsap4NgHZDN9r7RsPfcgEVmT3Ycln+owYNuLibQv1yoAH vjLitqYebrpR/jKpVJZ2XsCnWcxxblhwXok7dKItMbMDfR3sEw1wuZSkXaLhZukLD9mH YdPiCa1y1Vm9Xpp6XB2GmjgT7xZPmae6C/BVozg9Gb8aJ+cPlwMw6+2yy4sCKWvxltIg dqTvz3sOFqDSvhgLhPnUAFSnzNIdfHFY8xgqYvmZbmBPkZvqhaLTk5kI6sz2sD0+CtFL P8eA==
X-Gm-Message-State: ALoCoQkSOn+KgGFEjYeQZHlMgl99KkfKvWU2grb1rvX5R/UFGZQSq4idee3IM/578Tu+uxYC9/04
MIME-Version: 1.0
X-Received: by 10.152.234.76 with SMTP id uc12mr26267883lac.50.1411393312165; Mon, 22 Sep 2014 06:41:52 -0700 (PDT)
Received: by 10.25.159.84 with HTTP; Mon, 22 Sep 2014 06:41:52 -0700 (PDT)
In-Reply-To: <21536.9120.451498.905934@fireball.kivinen.iki.fi>
References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AE9DD47@TK5EX14MBXC292.redmond.corp.microsoft.com> <CAL02cgSsi603XL2o4S89pAw64yLv0JRZaDg823uiyuTkm02AHA@mail.gmail.com> <21527.63989.999440.801542@fireball.kivinen.iki.fi> <CAL02cgQKfQr_dQ=0-oY19G4rmYL3928UWFLBfhDAyspwMU7W9g@mail.gmail.com> <21529.16232.880915.215045@fireball.kivinen.iki.fi> <CAL02cgSRmP+iRYqTPUdcgTipeDw1H8TdF3AMP-ORSqOwiWJEcQ@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439BA59EB7@TK5EX14MBXC286.redmond.corp.microsoft.com> <CAL02cgRTmsVTkwwDMbHtcqHzCs6GkOz-uZ_SOKNeR3hxJZMdDw@mail.gmail.com> <03a601cfd460$f8d71d70$ea855850$@augustcellars.com> <C9BA46F1-5F30-47C7-A90A-689C5DA084F6@ve7jtb.com> <03c701cfd483$d1cf45e0$756dd1a0$@augustcellars.com> <F70DA0F7-A855-49A8-A514-39AB8862AF74@ve7jtb.com> <043a01cfd4f2$3df75ff0$b9e61fd0$@augustcellars.com> <457A8BF9-8CDF-43C8-8040-CB42BE110805@ve7jtb.com> <CAL02cgQfCRzUjrKLbyyNTFoKGxKrUnOqH1n6WS-SciWeBrgJzQ@mail.gmail.com> <21536.9120.451498.905934@fireball.kivinen.iki.fi>
Date: Mon, 22 Sep 2014 09:41:52 -0400
Message-ID: <CAL02cgTGg=9ZXbtom2ty3CwT2gSo2y3UjHhbFP4fc5h7+qgtuA@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Tero Kivinen <kivinen@iki.fi>
Content-Type: multipart/alternative; boundary="001a11340f1202a2150503a79d3b"
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/NSwlVKO_vp_jo28Buxi2v1V5BeU
Cc: "ietf@ietf.org" <ietf@ietf.org>, secdir <secdir@ietf.org>, Jim Schaad <ietf@augustcellars.com>, Michael Jones <Michael.Jones@microsoft.com>, IESG <iesg@ietf.org>, "jose@ietf.org" <jose@ietf.org>, John Bradley <ve7jtb@ve7jtb.com>, "draft-ietf-jose-json-web-signature.all@tools.ietf.org" <draft-ietf-jose-json-web-signature.all@tools.ietf.org>
Subject: Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Sep 2014 13:59:04 -0000

On Mon, Sep 22, 2014 at 9:26 AM, Tero Kivinen <kivinen@iki.fi> wrote:

> 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
> other.
>
> 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.
> --
> kivinen@iki.fi
>

Do you think the above is inaccurate or incomplete, or misses critical
detail?  The level of detail you're talking about doesn't really seem
appropriate for this spec, which is consuming crypto, not designing it.