Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31
Richard Barnes <rlb@ipv.sx> Mon, 22 September 2014 00:32 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 430261A0396 for <jose@ietfa.amsl.com>; Sun, 21 Sep 2014 17:32:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.723
X-Spam-Level:
X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 wsD4VdqVbtRI for <jose@ietfa.amsl.com>; Sun, 21 Sep 2014 17:32:07 -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 406981A039D for <jose@ietf.org>; Sun, 21 Sep 2014 17:32:03 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id q1so5788082lam.31 for <jose@ietf.org>; Sun, 21 Sep 2014 17:32:01 -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=/lHru6Plxk5l0mB5uxM89nE2j1YSu2SzfH3Gfnb/jkg=; b=g/19fSAUjm3K6/b1Jngqn2b0jqXnjk7AFOGqqBV1RHNmrtZzBNUc5OvovRVp3RgyKm FLgZZBIazFPvd8gr/c3cNoranTgcOWLb515q1ubr1Pl59i7Vm/wBuOl30MFB0DdnWcd7 AsuNgYfoTNpDpc7DQvXLNCpdQQp7fDwVBIopMvPxxrihvB5XUCW7eUPkGk5KrhKlYkZR ZLZf8QS1Bfdwgvp1hEinIa6RcT0RgDvAO76kUiE7cqwsauEWUrQd7k1Y9o0oeq/4lMN5 VvubCHSeAUSAQDINtxVZ15zxL8tQ5vtC3it3661vyOZTxje/69G5TBMPUHv3DPE5uiPp 0DcQ==
X-Gm-Message-State: ALoCoQkojQGh5bqeVmRHqz1yH/fz6uJiU0UepXeMmlZDzXFWeM5MPA2tzeDV1vTlEeJMk3vWzi1j
MIME-Version: 1.0
X-Received: by 10.152.6.40 with SMTP id x8mr21931287lax.18.1411345921192; Sun, 21 Sep 2014 17:32:01 -0700 (PDT)
Received: by 10.25.159.84 with HTTP; Sun, 21 Sep 2014 17:32:01 -0700 (PDT)
In-Reply-To: <457A8BF9-8CDF-43C8-8040-CB42BE110805@ve7jtb.com>
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>
Date: Sun, 21 Sep 2014 20:32:01 -0400
Message-ID: <CAL02cgQfCRzUjrKLbyyNTFoKGxKrUnOqH1n6WS-SciWeBrgJzQ@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary="089e0141a02049c41605039c9485"
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/DTaCT9dVEtqECgk4nSUZRXeTenA
Cc: "ietf@ietf.org" <ietf@ietf.org>, secdir <secdir@ietf.org>, Jim Schaad <ietf@augustcellars.com>, Tero Kivinen <kivinen@iki.fi>, Michael Jones <Michael.Jones@microsoft.com>, IESG <iesg@ietf.org>, "jose@ietf.org" <jose@ietf.org>, "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 00:32:09 -0000
I think I may have erred by trying to write a treatise on which algorithms are vulnerable :) Here's some updated text, trying to be more concise. Jim: Your points about SHA-256 vs. SHA-512/256 and SHA-256 vs. SHA-3 don't really apply, since JOSE hasn't defined algorithm identifiers for SHA-512/256 or SHA-3. """ # 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 strengths * 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 "PS256" and "PS384" as "alg" values, and a signer creates a signature using "PS256". If the attacker can craft a payload that results in the same signature with SHA-256 as the signature with SHA-384 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 using JOSE to mitigate algorithm substitution attacks The simplest mitigation is to not accept signatures using vulnerable algorithms: Algorithm substitution attacks do not arise for all signature algorithms. The only algorithms defined in JWA {{I-D.ietf-jose-json-web-algorithms}} that may be vulnerable to algorithm substitution attacks is RSA-PSS ("PS256", etc.). An implementation that does not support RSA-PSS is not vulnerable to algorithm substitution attacks. (Obviously, if other algorithms are added, then they may introduce new risks.) In addition, substitution attacks are only feasible if an attacker can compute pre-images for the weakest hash function accepted by the recipient. All JOSE algorithms use SHA-2 hashes, for which there are no known pre-image attacks as of this writing. Until there begin to be attacks against SHA-2 hashes, even a JOSE implementation that supports PSS is safe from substitution attacks. Without restricting algorithms, there are also mitigations at the JOSE and application layer: At the level of JOSE, an application could require that the "alg" parameter be carried in the protected header. (This is the approach taken by RFC 6211.) The application could also 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, not to accept vulnerable algorithms. 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. """
- Re: [jose] Secdir review of draft-ietf-jose-json-… Mike Jones
- Re: [jose] Secdir review of draft-ietf-jose-json-… Richard Barnes
- Re: [jose] Secdir review of draft-ietf-jose-json-… Tero Kivinen
- Re: [jose] Secdir review of draft-ietf-jose-json-… Tero Kivinen
- Re: [jose] Secdir review of draft-ietf-jose-json-… Richard Barnes
- Re: [jose] Secdir review of draft-ietf-jose-json-… Tero Kivinen
- Re: [jose] Secdir review of draft-ietf-jose-json-… Richard Barnes
- Re: [jose] Secdir review of draft-ietf-jose-json-… Mike Jones
- Re: [jose] Secdir review of draft-ietf-jose-json-… Mike Jones
- Re: [jose] Secdir review of draft-ietf-jose-json-… Richard Barnes
- Re: [jose] Secdir review of draft-ietf-jose-json-… Mike Jones
- Re: [jose] Secdir review of draft-ietf-jose-json-… Jim Schaad
- Re: [jose] Secdir review of draft-ietf-jose-json-… John Bradley
- Re: [jose] Secdir review of draft-ietf-jose-json-… Mike Jones
- Re: [jose] Secdir review of draft-ietf-jose-json-… Jim Schaad
- Re: [jose] Secdir review of draft-ietf-jose-json-… John Bradley
- Re: [jose] Secdir review of draft-ietf-jose-json-… Jim Schaad
- Re: [jose] Secdir review of draft-ietf-jose-json-… John Bradley
- Re: [jose] Secdir review of draft-ietf-jose-json-… Richard Barnes
- Re: [jose] Secdir review of draft-ietf-jose-json-… John Bradley
- Re: [jose] Secdir review of draft-ietf-jose-json-… John Bradley
- Re: [jose] Secdir review of draft-ietf-jose-json-… Richard Barnes
- Re: [jose] Secdir review of draft-ietf-jose-json-… Richard Barnes
- Re: [jose] Secdir review of draft-ietf-jose-json-… John Bradley
- Re: [jose] Secdir review of draft-ietf-jose-json-… Jim Schaad
- Re: [jose] Secdir review of draft-ietf-jose-json-… Richard Barnes
- Re: [jose] Secdir review of draft-ietf-jose-json-… Jim Schaad
- Re: [jose] Secdir review of draft-ietf-jose-json-… Tero Kivinen
- Re: [jose] Secdir review of draft-ietf-jose-json-… Richard Barnes
- Re: [jose] Secdir review of draft-ietf-jose-json-… Tero Kivinen
- Re: [jose] Secdir review of draft-ietf-jose-json-… Mike Jones
- Re: [jose] Secdir review of draft-ietf-jose-json-… Mike Jones
- Re: [jose] Secdir review of draft-ietf-jose-json-… Tero Kivinen
- Re: [jose] Secdir review of draft-ietf-jose-json-… Mike Jones
- Re: [jose] Secdir review of draft-ietf-jose-json-… Mike Jones