Re: [jose] Mxed Signature Algorithm TYpes
Richard Barnes <rlb@ipv.sx> Wed, 04 September 2013 22:42 UTC
Return-Path: <rlb@ipv.sx>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C9C11E811E for <jose@ietfa.amsl.com>; Wed, 4 Sep 2013 15:42:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivk0hJ6qHyHj for <jose@ietfa.amsl.com>; Wed, 4 Sep 2013 15:42:14 -0700 (PDT)
Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id E2D2C21E8083 for <jose@ietf.org>; Wed, 4 Sep 2013 15:42:13 -0700 (PDT)
Received: by mail-oa0-f51.google.com with SMTP id h1so1328623oag.10 for <jose@ietf.org>; Wed, 04 Sep 2013 15:42:13 -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=QfkzwcaqwdnnKDuCJWRCqrZmH78gUYqqUmbcMJaZRf8=; b=SyJG6qwAAPX9TMqgRM78ws9V4/pUXnzSAxV/LHvGj/0jDAGCiIBetq0W1gXeVudmeY Pi++7eBkttkonWIr+piMn0TySXEM0hMURm7RU4TfS7kmbpTUVs8GAYwiMcy4/dKonI5p fjge4Dp3N/aAKz8gapNRamL/iN7bQtYzyHsdjBv3SG8ClFKd2UHgV9z+EL0aZwtdv1jc Bachfw7Uq/2D4Pc/3hX11Aj5PRbmzCNCp4YVdFYg1RtTWq8fO6d8lnhOsax2u4sEcLwH LFMrra+blwb1Ti+mNB1UX9InyDZjJvCPYsh1urdzVBisWmUSGbg2UzD4SD7c2vV9EwbK G15Q==
X-Gm-Message-State: ALoCoQn+jsOKz/A9rFMeBYWD4BNGX4uln72UBtxXo6cy0I7m/Fglg4UhW7BYoH60hcS9zh4ZjBvR
MIME-Version: 1.0
X-Received: by 10.182.44.167 with SMTP id f7mr4058460obm.3.1378334533432; Wed, 04 Sep 2013 15:42:13 -0700 (PDT)
Received: by 10.60.31.74 with HTTP; Wed, 4 Sep 2013 15:42:13 -0700 (PDT)
In-Reply-To: <02d001cea8f2$f6e81540$e4b83fc0$@augustcellars.com>
References: <02d001cea8f2$f6e81540$e4b83fc0$@augustcellars.com>
Date: Wed, 04 Sep 2013 18:42:13 -0400
Message-ID: <CAL02cgQ4AjYg4TiM5FtRBzmsbOgpcFt1Mf7im0bsHO6g-NMq1Q@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Jim Schaad <ietf@augustcellars.com>
Content-Type: multipart/alternative; boundary="001a11c1d7e03f470904e596847e"
Cc: Mike Jones <Michael.Jones@microsoft.com>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] Mxed Signature Algorithm TYpes
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 04 Sep 2013 22:42:18 -0000
I'm not sure the difference is so great between MAC and (real) signature. If the recipient doesn't have the right MAC key(s), those signatures will just fail. I would certainly agree that "none" should never be mixed in. If the validator library is going to return an array of validation results (for example), it has to choose "true" or "false", neither of which is appropriate for "none". On Tue, Sep 3, 2013 at 6:14 PM, Jim Schaad <ietf@augustcellars.com> wrote: > A side question from this discussion that I would like to see addressed is > should we state any recommendations about mixing different types of > signatures algorithms in the same message.**** > > ** ** > > I would think that it makes sense to say that type types “none”, “mac” and > “asymmetric-Signature” should never be mixed in the same message because > these different types of algorithms have significantly different security > properties.**** > > ** ** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Tuesday, September 03, 2013 1:33 PM > *To:* Mike Jones > *Cc:* jose@ietf.org > *Subject:* Re: [jose] Text about applications and "alg":"none"**** > > ** ** > > This text is still far too weak, and does not reflect what I remember EKR > saying (in particular, there is no MUST). It does not address the attack > where an application may, in general, be willing to accept both signed and > unsigned content, but each in specific contexts. Proposed text:**** > > ** ** > > """**** > > JWS implementations MUST provide an interface for applications to specify > a list of "alg" values that are acceptable for the validation of a given > JWS object. JWS implementations MUST NOT indicate that a JWS object is > valid if the "alg" value for the object is "none", unless the application > has specifically indicated that the value "none" is acceptable for the > particular JWS object being validated. Applications using "none" MUST > indicate support on a per-object basis, in order to avoid downgrade attacks > that arise if more broadly-applicable preferences are specified.**** > > """**** > > ** ** > > I continue to believe that this is far too subtle, and that applications > are very likely to get it wrong. It is far simpler and safer to require > that a JWS implementation MUST reject an object with "alg":"none", and have > another content type for unsigned content.**** > > ** ** > > Also, if "none" is going to remain, then it needs to be OPTIONAL. Given > all the above limitations, I don't see how you could justify it being > mandatory.**** > > ** ** > > --Richard**** > > ** ** > > ** ** > > On Tue, Sep 3, 2013 at 2:02 PM, Mike Jones <Michael.Jones@microsoft.com> > wrote:**** > > I took an action item during the last call to write text along the lines > suggested by ekr about applications and "alg":"none". I propose that the > following text be included:**** > > **** > > It is RECOMMENDED that libraries provide applications a means of > specifying the list of acceptable algorithms used in a JWS object in a way > that causes inputs using algorithms outside the specified set to be > rejected. In particular, it is intended for applications to use this > mechanism to exclude accepting inputs using "alg":"none" in security > contexts where non-integrity protected inputs are not acceptable.**** > > **** > > Feedback/proposed wording refinements welcomed.**** > > **** > > -- Mike*** > * > > **** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** >
- [jose] Mxed Signature Algorithm TYpes Jim Schaad
- Re: [jose] Mxed Signature Algorithm TYpes Jim Schaad
- Re: [jose] Mxed Signature Algorithm TYpes Richard Barnes
- Re: [jose] Mxed Signature Algorithm TYpes Mike Jones