Re: [secdir] [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: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACEA1A1AC2 for <secdir@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 FFFUciXc_yCA for <secdir@ietfa.amsl.com>; Mon, 22 Sep 2014 06:59:03 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E587B1A1ADF for <secdir@ietf.org>; Mon, 22 Sep 2014 06:41:53 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id q1so6763235lam.31 for <secdir@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=nHDzGXmvD+QKe/o+/xI/5KBRsgIUqqUeSTD6+QB2Ghp5YSVnYdOXwq9DJ0FnZYaCRz jYYCvDyPLZumq5BF7rqZeyZVkv5HFnZPkrKS30JRZ2y1dk09eDQ3K/Cy5sbl8/SFau9G xSZqoAU2Y8tNnyp7e+F3UZBg3pnMhCG774BJQBurBltq1kpIOoanfHFo7Tt5skrIeCIx 4/JCfnBQlm+1U+QM96clACd4JAifmy/a+op1fLJnsHZgwk7vOciRpA78qlkV9rVT9rks u/67RtW1/ua3+dcIe0SH6lpoLHx+HNaPW52D043PHO3gU4Dzv0QdrFx3x7skWKSKfEOl ikSA==
X-Gm-Message-State: ALoCoQl4wKTBROmeTkTMRVSnpeDzAjaJSbwdbtodwIDJKubHYCgCKvaBQ0hZeAWBabEhErSWu/6c
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/secdir/aMDoN4H1OInVKxYsSLlPJOYVy2c
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: [secdir] [jose] Secdir review of draft-ietf-jose-json-web-signature-31
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-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.