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

Richard Barnes <rlb@ipv.sx> Wed, 17 September 2014 03:50 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 2D0C41A01A9 for <secdir@ietfa.amsl.com>; Tue, 16 Sep 2014 20:50:34 -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=ham
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 T277VPMK8UeT for <secdir@ietfa.amsl.com>; Tue, 16 Sep 2014 20:50:32 -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 6641F1A019C for <secdir@ietf.org>; Tue, 16 Sep 2014 20:50:31 -0700 (PDT)
Received: by mail-lb0-f180.google.com with SMTP id b12so1047572lbj.11 for <secdir@ietf.org>; Tue, 16 Sep 2014 20:50:29 -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=rNDrKSZXh4J8cT/ja0+NRORSYPIWxAoEJ7QbQ4z+01E=; b=CAHP6z3F5N7Zv/lVnZOchhwP+CntV5FqOhEA3nTW9EcKi4EO11eD+sNOWXfh/JuCi1 XQ1tYWjl5lRcjRw3GyhjyRceTiCTWhseCryJEY8/0c8IJ7vtGrWGXCsGzXjpJ/hznTiP Wbkk4Uo/djEa41VTo3JeoxO+JTpBL1EiGjgh6UJTlqNQaHu2rmICzBqn4T/HBmGBN+07 5BEF9HUSY3r1UDYQeUnzbMooJ+C+rDBqcfOx/pWneOMvCo6yscDOicG2zt6/37GG1A6K B76G0Q/r/2wRwcznbzHAIA5Dz836JPWDGhnuBj2t2pVXexNncZTvYQvkRnZUEebxr+d3 8SsA==
X-Gm-Message-State: ALoCoQnmuKJXqCWM2K+02L7ApJO4jigPmARxFwCfFX/zHaWvqhqd33hWyl1Qiutlu7/KJyJbgCoG
MIME-Version: 1.0
X-Received: by 10.152.179.226 with SMTP id dj2mr41555248lac.40.1410925829579; Tue, 16 Sep 2014 20:50:29 -0700 (PDT)
Received: by 10.25.159.84 with HTTP; Tue, 16 Sep 2014 20:50:29 -0700 (PDT)
In-Reply-To: <21527.63989.999440.801542@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>
Date: Tue, 16 Sep 2014 23:50:29 -0400
Message-ID: <CAL02cgQKfQr_dQ=0-oY19G4rmYL3928UWFLBfhDAyspwMU7W9g@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Tero Kivinen <kivinen@iki.fi>
Content-Type: multipart/alternative; boundary=001a1133a57ce0797805033ac46d
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/aJU9XntIi4j89_ePHIu8g66K7TA
Cc: "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, Mike Jones <Michael.Jones@microsoft.com>, "iesg@ietf.org" <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] 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: Wed, 17 Sep 2014 03:50:34 -0000

On Tue, Sep 16, 2014 at 4:51 AM, Tero Kivinen <kivinen@iki.fi> wrote:

> Richard Barnes writes:
> >>>     1) "alg" and Protected Header
> >>>
> >>>     Question: Shouldn't the "alg" header parameter be protected by
> >>>     the signature, i.e. wouldn't it make sense to say MUST be in
> >>>     the "Protected Header"?
> >>>
> >>>     I think the draft needs text saying something about the
> >>>     situation where "alg" is not in "Protected Header" in the
> >>>     security sections section. I.e. either say, that it has been
> >>>     analyzed that there is no problem even when the "alg" is not
> >>>     protected, and reference to such analysis, or otherwise add
> >>>     text/warning that it MUST/SHOULD be in the "Protected Header".
> >>>     I do not know enough about the proposed signature algorithms
> >>>     to know which one is true, especially as there might be new
> >>>     algorithms in the future.
> >>>
> >>     Richard Barnes, do you want to answer this one?  You were the
> >>     primary advocate for allowing the algorithm to be unprotected
> >>     in the JSON Serialization.
> >>
> >>     As I recall, the motivation had to do with the fact that, by
> >>     default, CMS does not protect the algorithm (although it was
> >>     later extended to enable it to be protected).  Some others in
> >>     the working group thought that having unprotected algorithms
> >>     was a bad idea, in line with your comment above.
> >
> > The only need for protection of the "alg" value is to prevent algorithm
> > substitution attacks, as discussed in RFC 6211.
> > https://tools.ietf.org/html/rfc6211
> >
> > These attacks are fairly limited in their applicability, since they
> require
> > that:
> >  * The attacker is able to compute an input that is valid for the
> signature
> > using a different, weaker algorithm
> >  * The attacker's input is valid according to whatever application rules
> are
> > being applied
> >  * A relying party will accept the weaker algorithm
> >
> > Given all those criteria, it seems reasonable that some signers
> > might regard algorithm substitution attacks as an acceptable risk.
>
> Perhaps, but is there benefits for leaving the alg without protection?
>

Simplicity (if you omit protected headers altogether), and compatibility
with other signed things.  In the sense that you could transform one of
them into a JWS without re-signing.  This would apply, for example, to an
X.509 certificate -- just parse the outer SEQUENCE, and re-assemble into a
JWS with the tbsCertificate as payload.  Same security properties that
X.509 already has.

It's also completely unnecessary for PKCS#1 signatures, which are the
dominant use case today.

In general, I'm opposed to protocols baking in more application-specific
logic than they need to.  The point of JOSE is to describe the
cryptographic operation that was performed, and carry the relevant bits
around.  Its job is not to fix all the weaknesses that every algorithm
has.

--Richard



> > For example, in an application that set explicit minimum algorithm
> > requirements (e.g., SHA-3 only!), there may be no risk of a relying
> > party accepting the weaker algorithm.  Or the application payload
> > might have low enough entropy that it's impossible to find a valid
> > forged input.
> >
> > And if an application is concerned about algorithm substitution
> > attacks, it can protect itself by including the algorithm in the
> > payload, as X.509 does.
>
> Having this kind of options which might or might not have security is
> usually bad. So I would suggest that unless there is use case or real
> reason why the alg should NOT be protected all the time, make it
> protected always.
>
> > I would be happy to have some advisory text in the security
> > considerations, but I don't think this rises to the level of
> > SHOULD/MUST.
>
> I hate to be there in ten years, when someone finds out problems with
> this prorotocol, as someone decided to add some new algorithms, and
> someone then decided to use the feature include, i.e. having alg
> unprotected, and then the combination suddenly causes problems...
>
> So if there is no reason to keep it that way, I would be much more
> happy to say that it must be protected always.
> --
> kivinen@iki.fi
>