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

Richard Barnes <rlb@ipv.sx> Mon, 22 September 2014 01:32 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 6FD4B1A0439 for <secdir@ietfa.amsl.com>; Sun, 21 Sep 2014 18:32:00 -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 lRrRqW9Gpbix for <secdir@ietfa.amsl.com>; Sun, 21 Sep 2014 18:31:58 -0700 (PDT)
Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3386A1A03A5 for <secdir@ietf.org>; Sun, 21 Sep 2014 18:31:55 -0700 (PDT)
Received: by mail-lb0-f177.google.com with SMTP id z12so5875813lbi.36 for <secdir@ietf.org>; Sun, 21 Sep 2014 18:31:53 -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=hbQtFlkRhtDk8RpUYSpKC4Kl1TATV4Cr4U8ACz1LsFQ=; b=AyZlipkcOcoUrLHyUxSJ0VPEMNk5XereF8vDo+n6LHb8WY348NRo1tinEZrN77LXlr hAPWE9JHqAseo7XJvqrJjWRHH7MsI+ZYeWjPGufpnQS5Bc/ctfMbP5wta1p2EbJvswWP TzbASWEzLiVuC1y5k7dfTTIJO+OOr4pHZh3oEd2+TVJ8kXxEuJPo6S4Mh/NUstPU/zXc gGPkGdsAkFUUKc1oLfjZyJ/f5fiMtx89jJhh1kXfprsMEVwicrTlQ5UOMIkvv2vrAARS OJTHD/UPVLFglnzPaKMsze65myDIal7cjw+xx4JVxKtpBxBc6dbCF+V1GNeGBrTVM7EX 2z0Q==
X-Gm-Message-State: ALoCoQkm+DRpo+WTmmfV59pZX49IZrqGuAogrUBsV+dSOEz/dLxqfW80S6C8eFJv4eDUJWmhViot
MIME-Version: 1.0
X-Received: by 10.112.148.170 with SMTP id tt10mr21503385lbb.61.1411349513437; Sun, 21 Sep 2014 18:31:53 -0700 (PDT)
Received: by 10.25.159.84 with HTTP; Sun, 21 Sep 2014 18:31:53 -0700 (PDT)
In-Reply-To: <5EF71157-1102-4863-8DC1-2B2A397A4532@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> <CAL02cgQfCRzUjrKLbyyNTFoKGxKrUnOqH1n6WS-SciWeBrgJzQ@mail.gmail.com> <BEE36F1F-2B23-4527-AF91-7EDF0471066F@ve7jtb.com> <5EF71157-1102-4863-8DC1-2B2A397A4532@ve7jtb.com>
Date: Sun, 21 Sep 2014 21:31:53 -0400
Message-ID: <CAL02cgRfG2LS_4PWbuw=XsG4PrYYC6rExuz36p9z8mdM8g6SSQ@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary=047d7b3a7d8e67085c05039d6a4e
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/nsMsy1dHlzaR5AdcSDM_4rCqGfs
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>, "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 01:32:00 -0000

On Sun, Sep 21, 2014 at 8:59 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

> Also with PSS the attack is largely mitigated if the mask function uses
> the same hash as the message. http://tools.ietf.org/html/rfc3447#page-29
>
> JWA sec 3.5  requires SHA2 MGF functions for SHA2 message hashes with the
> equivalent length.
>
> If the same is done when SHA3 is added then I think PSS is not as
> susceptible to a substitution attack as it might look on the surface.
>

Certainly, having to change the MGF makes things much harder for the
attacker.  However, in principle an attacker with a sufficiently broken
hash algorithm could compute a preimage for the message *and* the MGF.  As
RFC 3447 says:

"it will be difficult for an opponent to substitute a different hash
function"

... using "difficult" in the sense of "way harder than if we hadn't", not
in the sense of "just as hard as forging the signature".

--Richard




> Sorry I just remembers that there was that mitigation for PSS.
>
> John B.
>
> On Sep 21, 2014, at 8:47 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>
> I like the general direction.
>
> One question,  wouldn't the recipient of a PSS signature detect the
> substitution of SHA-284 with SHA-256 due to the different key length.
>
> I was under the perhaps mistaken impression that the key lengths needed to
> be the same and just the alg different eg SHA3 and SHA2 keys of the same
> length.
>
> If that is the case we probably have not defined any algs currently that
> may be subject to this.  That is not to say that we shouldn't warn people
> as new algs are defined.
>
> John B.
>
>
> On Sep 21, 2014, at 8:32 PM, Richard Barnes <rlb@ipv.sx> wrote:
>
> 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.
> """
>
>
>
>