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

Richard Barnes <rlb@ipv.sx> Tue, 04 November 2014 03:12 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 A7F631A888A for <jose@ietfa.amsl.com>; Mon, 3 Nov 2014 19:12:46 -0800 (PST)
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 Gzby_ddgpu7p for <jose@ietfa.amsl.com>; Mon, 3 Nov 2014 19:12:43 -0800 (PST)
Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB711A7014 for <jose@ietf.org>; Mon, 3 Nov 2014 19:12:43 -0800 (PST)
Received: by mail-vc0-f176.google.com with SMTP id hq12so2647950vcb.7 for <jose@ietf.org>; Mon, 03 Nov 2014 19:12:42 -0800 (PST)
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=ovwEN8GCVsSCVMA7iI7VRJRWxspi6fk68NK3yKPV0wY=; b=lc3WPxG5queislfviLA0cCEHwCpKDLDNR2FMHJVhQX1RntjnLkKgUrtinmMfO+QB6m ta6r4CELL/xH2VNbxjsHTRxV5gNPMb+tJWcEjbcTaC37Htxw+bcXy4NjhhzPD11m0XvK Iv9lLU5kZuRe5kVAVKQyA0RpHisLlxbKekEI90XWyVMXMLbas50pVVxnbOJC0xzy0ElA vwSWIqkqO8B46z2sngyv1NadFm/j7a14H80rma4h9Nbb7IEDYhCg0eYlQ1faH/Hk9aMf RXYhuP1+0pv/9igB6AlSGDPUsXnw3yF2OuLWUiElezZLkR451y0+lFIuPcLbhrGBvtHB eGvg==
X-Gm-Message-State: ALoCoQl6Mv65FOjiC4RWm75sSQS6cWfCAnbCEoGuDcU3AhzCBYrlINAT3j71BAwIoXw2xPr3Wy6Y
MIME-Version: 1.0
X-Received: by 10.221.68.199 with SMTP id xz7mr41516507vcb.7.1415070762311; Mon, 03 Nov 2014 19:12:42 -0800 (PST)
Received: by 10.31.149.205 with HTTP; Mon, 3 Nov 2014 19:12:42 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BB1E2D8@TK5EX14MBXC286.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B16804296739439BB0D32E@TK5EX14MBXC286.redmond.corp.microsoft.com> <00e501cfeb2e$26744210$735cc630$@augustcellars.com> <CAL02cgTbaZyq0oDnA6nO_FX9TzzWg3d4d=6oNT0VHcCb5_C3Lw@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439BB1E2D8@TK5EX14MBXC286.redmond.corp.microsoft.com>
Date: Mon, 3 Nov 2014 22:12:42 -0500
Message-ID: <CAL02cgTA+CGNQY0xToK0RaxJUBodq9xge=oat8L=HKn_hy4y4w@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary=001a11339ffa1ebcdf0506ffd6de
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/5nfhXU8jKJMqSnUAsVKdlfzqwjo
Cc: Jim Schaad <ietf@augustcellars.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: Tue, 04 Nov 2014 03:12:46 -0000

On Tue, Oct 21, 2014 at 2:58 PM, Mike Jones <Michael.Jones@microsoft.com>
wrote:

> > > > > > 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.
>
> I think Jim laid out the attack pretty clearly, but I understand that
> perceptions vary.  Given that you're asking to relax the security
> properties of the draft and Jim believes that the current language
> mitigates a real attack or attacks, I don't think that as editor I should
> relax the security properties without clear direction from the working
> group to do so, and in particular, without an agreement from Jim that the
> attack isn't real or doesn't matter.  Discussions can obviously continue on
> this, and at least as I see it, will need to unless you're willing to
> declare yourself in the rough on this, Richard.
>

To be clear, I'm not proposing that we relax the security properties.  I'm
proposing that a mechanism that the document claims provides security
properties actually doesn't, and thus creates needless complexity for
implementors.

--Richard




>
>                                 Thanks again,
>                                 -- Mike
>
> > --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.
> > > > >
>