Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)

Richard Barnes <rlb@ipv.sx> Mon, 20 October 2014 15:59 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 E2A4D1A1B1C for <jose@ietfa.amsl.com>; Mon, 20 Oct 2014 08:59:03 -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 Xi7iPW3oCC5L for <jose@ietfa.amsl.com>; Mon, 20 Oct 2014 08:58:58 -0700 (PDT)
Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2921A1B69 for <jose@ietf.org>; Mon, 20 Oct 2014 08:57:50 -0700 (PDT)
Received: by mail-vc0-f169.google.com with SMTP id hy4so3781955vcb.14 for <jose@ietf.org>; Mon, 20 Oct 2014 08:57:49 -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=bUPSmlCN112l2RGFNYTsmkKxixjZLd3wwxX9n7UbK2g=; b=TmSdG/gGexGZWNITUvsQst9f6r/Ni4pWC1TvVuQyHSezcaMcKnkdUxRxlsIIY8zqKt CVfMKAekyJPmm66LDLb8HJ4wg2j2Nws+wzfNv3iXuzlGOjiEPN/5PfAeScWtdoT8MpZW 9HWdcYzz4lyCIOa9YGIStRtDK2vGaYlOL6vHOQnKdRSQTnfwDyH1rorlQmd6iHrK60ID ZaHM48SMouO8VAhh06oxifoTz8q4zVrU7AkQRlbcB1t1vRy0+dwph6W0ls0Ii6D/QC1k 6nLifxRt2DVS5BrdrKHDwvlwgoDP4BLFWzJaScgIVfT8+pW+2sJQ+QiZlPsS/XXUFDaS OSsg==
X-Gm-Message-State: ALoCoQkCYgVC3hXqNiu43JfAH2YOWF9VFXKP/i/UOwh+ZXi886PKm713viXEHRKuTGTh85G/qJAC
MIME-Version: 1.0
X-Received: by 10.220.1.15 with SMTP id 15mr10095589vcd.39.1413820669077; Mon, 20 Oct 2014 08:57:49 -0700 (PDT)
Received: by 10.31.149.205 with HTTP; Mon, 20 Oct 2014 08:57:49 -0700 (PDT)
In-Reply-To: <00e501cfeb2e$26744210$735cc630$@augustcellars.com>
References: <4E1F6AAD24975D4BA5B16804296739439BB0D32E@TK5EX14MBXC286.redmond.corp.microsoft.com> <00e501cfeb2e$26744210$735cc630$@augustcellars.com>
Date: Mon, 20 Oct 2014 11:57:49 -0400
Message-ID: <CAL02cgTbaZyq0oDnA6nO_FX9TzzWg3d4d=6oNT0VHcCb5_C3Lw@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Jim Schaad <ietf@augustcellars.com>
Content-Type: multipart/alternative; boundary=001a11c3cc02c1bf940505dcc64b
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/VeQvnQP4WYE-DFF9O7MGU6TKlKY
Cc: Mike Jones <Michael.Jones@microsoft.com>, "jose-chairs@tools.ietf.org" <jose-chairs@tools.ietf.org>, The IESG <iesg@ietf.org>, "jose@ietf.org" <jose@ietf.org>, "draft-ietf-jose-json-web-signature@tools.ietf.org" <draft-ietf-jose-json-web-signature@tools.ietf.org>
Subject: Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)
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, 20 Oct 2014 15:59:04 -0000

On Sat, Oct 18, 2014 at 7:49 PM, Jim Schaad <ietf@augustcellars.com> wrote:

>
>
> > -----Original Message-----
> > From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> > Sent: Tuesday, October 14, 2014 5:47 AM
> > To: Richard Barnes
> > Cc: The IESG; jose-chairs@tools.ietf.org; jose@ietf.org;
> draft-ietf-jose-json-
> > web-signature@tools.ietf.org
> > Subject: RE: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-
> > signature-33: (with DISCUSS and COMMENT)
> >
> > > -----Original Message-----
> > > From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> > > Sent: Saturday, October 11, 2014 2:15 PM
> > > To: Richard Barnes
> > > Cc: The IESG; jose-chairs@tools.ietf.org; jose@ietf.org;
> > > draft-ietf-jose-json- web-signature@tools.ietf.org
> > > Subject: RE: [jose] Richard Barnes' Discuss on
> > > draft-ietf-jose-json-web-
> > > signature-33: (with DISCUSS and COMMENT)
> > >
> > > > From: Richard Barnes [mailto:rlb@ipv.sx]
> > > > Sent: Friday, October 10, 2014 3:20 PM
> > > > To: Mike Jones
> > > > Cc: The IESG; jose-chairs@tools.ietf.org; jose@ietf.org;
> > > > draft-ietf-jose-json-web-signature@tools.ietf.org
> > > > Subject: Re: [jose] Richard Barnes' Discuss on
> > > > draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)
> > > >
> > > > On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones
> > > <Michael.Jones@microsoft.com> wrote:
> > > > Thanks for your review, Richard.  I'm repeating my previous
> > > > responses from
> > > my Thursday reply, but this time using ">" quoting rather than colors,
> > > for better readability by people not using HTML-enabled mail readers...
> > > >
> > > > > -----Original Message-----
> > > > > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Richard
> > > > > Barnes
> > > > > Sent: Wednesday, October 01, 2014 9:22 PM
> > > > > To: The IESG
> > > > > Cc: jose-chairs@tools.ietf.org; jose@ietf.org;
> > > > > draft-ietf-jose-json-web- signature@tools.ietf.org
> > > > > Subject: [jose] Richard Barnes' Discuss on
> > > > > draft-ietf-jose-json-web-signature-
> > > 33:
> > > > > (with DISCUSS and COMMENT)
> > > > >
> > > > > ------------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > DISCUSS:
> > > > > ------------------------------------------------------------------
> > > > > --
> > > > > --
> > > > >
> > > > > Section 6.
> > > > > """
> > > > > These Header Parameters MUST be integrity protected if the
> > > > > information that they convey is to be utilized in a trust decision.
> > > > > """
> > > > > This smells really fishy to me.  What's your attack scenario?  I'm
> > > > > pretty certain that there's no way any of these fields can be
> > > > > altered in such a way that (1) the signature will validate, and
> > > > > (2) the recipient will accept a key it shouldn't.  By way of
> > > > > contrast, CMS doesn't sign the certificate fields, and the
> > > > > Certificate payload in TLS is only signed as a side effect of the
> > > > > protocol's verification that the
> > > remote end has been the same through the whole handshake (which
> > > doesn't apply here).
> > > >
> > > > The attack scenario is trivial to describe.  If an attacker can
> > > > change
> > > information used in a trust decision, the trust decision has no
> > > validity.  Unless the information is integrity-protected, the attacker
> > > could change the non- integrity-protected portions of the JWS in an
> > undetectable way.
> > > >
> > > > That's hand waving, not an attack scenario.  Allow me to elaborate on
> > this:
> > > >
> > > > There is no possible attack scenario for the key identifiers that
> > > > identify a *key*
> > > (vs. a cert) -- jwk, jku, and kid.  For any given signed object, there
> > > is exactly one key that can validate the signature (otherwise the
> > > crypto is broken).  If the attacker changes the validation key, then
> > > the signature won't validate.  So there is no need to integrity
> > > protect these headers, since there's no point to the attacker changing
> > them.  RFC 2634 actually has text to this effect:
>
> There is a difference between how a key is referenced and how a key
> reference is used in a trust decision.
>
> This is the difference between:
> Here is where you go to get the key, and you know the key is associated
> with the entity because you have it in your database someplace, and
> Here is where you go to get the key, and you know the key is associated
> with the entity because the URL is parsed to get that information.
>
> In the first case, there is no need to sign the pointer to the key.  In
> the second case there is.  Possible attack below:
>
> If you use the URL:  "https://augustcellars.com/jose-signing-key" and you
> make a trust decision that the key is associated with augustcellars.com,
> then this should be signed.  If  not then it the same key could be
> published by "https://augustwest.com/jose-signing-key" (just a simple
> copy) and the jku changed to point to the new address.  In this case you
> don't know who actually signed the object, just that the key can be used to
> verify the signature successfully.
>

I'm not clear on what security property you think this is violating.

If you've made the decision to trust both augustcellars.com and
augustwest.com to assert trusted keys, then you've trusted augustwest.com
and there's no issue.

If you're using the domain name in the HTTPS URI to identify the signer,
then all augustwest.com can do is make it look as though it signed the
object, which it could have done anyway with a different key.  It can't
make it look as though augustcellars.com signed the object when it didn't.

Still not seeing an attack here.

--Richard



>
> Jim
>
> > > >
> > > > """
> > > >    The first version of this attack is a simple denial of service
> attack
> > > >    where an invalid certificate is substituted for the valid
> > > >    certificate. This renders the message unverifiable, as the public
> key
> > > >    in the certificate no longer matches the private key used to sign
> the
> > > >    message.
> > > > """
> > >
> > > It's not clear to me that enabling the attacker to substitute keys and
> > > get the recipient to attempt to validate the signature with a key of
> > > the attacker's choosing doesn't constitute at least a portion of a
> > > viable attack scenario.  It may or may not (knowing for sure is beyond
> > > my specific cryptographic expertise in this area) and it may not now
> > > but may be in the future (when new attacks are created).  Requiring
> > > these parameters to be integrity protected when used in a trust
> decision
> > does no harm and may do substantial good.
> > >
> > > > With regard to the certificate identifiers ("x5u", "x5c", "x5t", and
> > > > "x5t#S256"),
> > > the risks that Jim points out [RFC2634, Section 5] are real, but only
> > > apply in certain narrow circumstances.  Namely, the only time a risk
> > > arises is when two certificates have been issued for the same public
> key,
> > with different attributes.
> > > This is exceedingly rare in practice, and all current secure messaging
> > > systems get along fine without protection against this attack.  And it
> > > might not even be an attack -- you could envision cases with "x5u"
> > > where the signer purposely presents different certificates to different
> > relying parties!
> > > > So the blanket requirement that these fields MUST be integrity
> > > > protected is not
> > > appropriate.  It is only required for certain special situations using
> > certificates.
> > > Proposed revision:
> > > > Delete: "These Header Parameters MUST be integrity protected if the
> > > information that they convey is to be utilized in a trust decision."
> > >
> > > Researching the history a bit more, this text was added to address
> > > issue #104
> > > http://trac.tools.ietf.org/wg/jose/trac/ticket/104 raised by Jim
> > > Schaad.  Unless Jim agrees that it is now somehow unnecessary, I don't
> > > believe that it's reasonable for us to now remove it.  Also, see Jim's
> > > related comments about trust statements and trust decisions in issue
> #74.
> > >
> > > > Add new paragraph: "In situations where multiple certificates with
> > > > different
> > > attributes may be issued over the same public key, there is a risk
> > > that one of these certificates may be substituted for another. In such
> > > situations, the creator of a JWS object MUST integrity protect the
> "x5u",
> > "x5c", "x5t", and "x5t#S256"
> > > attributes, if present."
> > > >
> > > > For what it's worth, Sean had us add language in a number of places
> > > > that
> > > basically said that information is only as trustworthy as its source
> > > and the means by which it is obtained.  If I remember correctly, this
> was
> > one of those places.
> > > >
>
>
>