Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31
Richard Barnes <rlb@ipv.sx> Mon, 22 September 2014 02:21 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 4F5381A19EC for <jose@ietfa.amsl.com>; Sun, 21 Sep 2014 19:21:50 -0700 (PDT)
X-Quarantine-ID: <EGP0-VtLJx2G>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BANNED, message contains text/plain,.exe
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 EGP0-VtLJx2G for <jose@ietfa.amsl.com>; Sun, 21 Sep 2014 19:21:48 -0700 (PDT)
Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E6911A19F3 for <jose@ietf.org>; Sun, 21 Sep 2014 19:21:45 -0700 (PDT)
Received: by mail-la0-f50.google.com with SMTP id ty20so5842671lab.37 for <jose@ietf.org>; Sun, 21 Sep 2014 19:21:43 -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=rRpnwyw/BIeuWzzbE4H+zMg21S73NRNISXYaRJsaoH0=; b=UAWHj/sGyTPW1aXH0EvrQA1Nxe+LZmKE+8NIEvUj3wo/zBtyBmZoNOXPT1G0HYO/PW S3hJC4kFlcG5A9G0VNAfUVukbFXhLTt6qlWJHmG6vtfzYzLwWx3IKxPyBA5cWgqdNeiv DxQ8FI4QEgoTQGIiF7UxwCvozATGheP5qg4JFej+9oCu/dL9SVqhHkcy550I2VEB4FYH 9YHbXZbdFx17+7T13y3CmvwLHkuOKLXG/YmYnNtMK+QUnMAsAbKRI3Ozl/MLZ3PdP/Zd 2OJx6PPyhTIKfSlqux/8e4djeUjR0/FwQm0U0JZt4DQRZo6nCN+jU4ClS/3HTJ5MlHGF Ylwg==
X-Gm-Message-State: ALoCoQkVIfTXQDANlNX4C48zo46jwHyqf03rK5yegVCOePNq5272wbv4goYMZTAcu3WP5kE2M5XQ
MIME-Version: 1.0
X-Received: by 10.112.204.197 with SMTP id la5mr21297452lbc.2.1411352503674; Sun, 21 Sep 2014 19:21:43 -0700 (PDT)
Received: by 10.25.159.84 with HTTP; Sun, 21 Sep 2014 19:21:43 -0700 (PDT)
In-Reply-To: <04fd01cfd60a$71d0cc80$55726580$@augustcellars.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> <CAL02cgQfCRzUjrKLbyyNTFoKGxKrUnOqH1n6WS-SciWeBrgJzQ@mail.gmail.com> <04fd01cfd60a$71d0cc80$55726580$@augustcellars.com>
Date: Sun, 21 Sep 2014 22:21:43 -0400
Message-ID: <CAL02cgR-zrG5nOhHi0e6Rb6pkkDR7JaPeUugi0YkKydYueVDRQ@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Jim Schaad <ietf@augustcellars.com>
Content-Type: multipart/alternative; boundary="001a11c3c178a27dcd05039e1c6d"
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/tkAleNn6XFIFzjVX_jN7uSXRLP8
Cc: "ietf@ietf.org" <ietf@ietf.org>, secdir <secdir@ietf.org>, Tero Kivinen <kivinen@iki.fi>, 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 02:21:50 -0000
On Sun, Sep 21, 2014 at 10:10 PM, Jim Schaad <ietf@augustcellars.com> wrote: > > > > > *From:* jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Richard Barnes > *Sent:* Sunday, September 21, 2014 5:32 PM > *To:* John Bradley > *Cc:* ietf@ietf.org; secdir; Jim Schaad; Tero Kivinen; Michael Jones; > IESG; jose@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 > > > > 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. > > > > [JLS] Richard – are you planning to update this text when (not if) they > are defined? If not then this is still part of the problem even if > currently not constrained. The same could also be said to be not a problem > for all of the ECDSA algorithms since there is only one hash defined of any > given length. (I will ignore the really fun problem for DSA and ECDSA > where there is a modulus operation that occurs on the hash value thus > creating collisions within the same hash function and making matching of > hash function lengths and key lengths of primary importance.) However, as > these will almost certainly be defined in the future, they merit inclusion > in the potential problems. I believe that this should be included in the > discussion as it is much easier to do than to break the mask function of > RSA. (Breaking the same hash function twice is very non-trival, having two > hash functions that produce the same length hash is much easier.) > Is the phrase "Obviously, if other algorithms are added, then they may introduce new risks" insufficient? --Richard > > """ > # 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