Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)
Richard Barnes <rlb@ipv.sx> Thu, 20 November 2014 22:19 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 A16071A884D for <jose@ietfa.amsl.com>; Thu, 20 Nov 2014 14:19:51 -0800 (PST)
X-Quarantine-ID: <fdtAVp2kF9Hk>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BANNED, message contains text/plain,.exe
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 fdtAVp2kF9Hk for <jose@ietfa.amsl.com>; Thu, 20 Nov 2014 14:19:47 -0800 (PST)
Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFBD1A8828 for <jose@ietf.org>; Thu, 20 Nov 2014 14:19:46 -0800 (PST)
Received: by mail-vc0-f180.google.com with SMTP id im6so1850009vcb.11 for <jose@ietf.org>; Thu, 20 Nov 2014 14:19:45 -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=AS//A16z9BZGxHXxMnXP03neRH8Hb2eweCW1WRMLwao=; b=M85DKRYitPjJF9RkQ1GsAPr9JFaPGqmcIA4GGwVf+7qkDkO+DPPB6gZNiwI7BRO1Gj RLxkVXt6T0F5U9rnAP/cYrt/EVpKIzidJXol67siWxu35mWFT56y8s88FQX2Fu7vVWcg FDzs8WXq9XTvGJVrjY8a89jiJQavFY34I+WZjZDxPGQfh6MSN+yUpnEpJqA3IkY4TNxT Wu7PQSv90gsVcNa/tjPB8YEJryG68VcBfV/leo52iXtOqZRWB4lMWq2eqhXohY786tDk SVcZr8azsAFdHsyt9ilIS8PWR+9bu0hDgvCPAjqJkrkdVxUzPOFMgTNbTk9VwmfEtzuk QDxQ==
X-Gm-Message-State: ALoCoQmmTE5i+Ce8SXhx+N5XEwTPGK6GvHyVZMmE2/mQo+AeqHSepThjFb0JPLd9PE9/C7dYkfqG
MIME-Version: 1.0
X-Received: by 10.221.22.136 with SMTP id qw8mr830052vcb.77.1416521985807; Thu, 20 Nov 2014 14:19:45 -0800 (PST)
Received: by 10.31.149.1 with HTTP; Thu, 20 Nov 2014 14:19:45 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BB8DD22@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> <CAL02cgQN1RCSsbs4wx1gU2Y1jcsQs2Xe0NOpQyB5PLZsJSZGXg@mail.gmail.com> <CAL02cgSM-+wyNjgc_-rSh7aYWa7kNTdj3x560th0UsRLpbNLfQ@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439BB81460@TK5EX14MBXC286.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439BB8DD22@TK5EX14MBXC286.redmond.corp.microsoft.com>
Date: Thu, 20 Nov 2014 17:19:45 -0500
Message-ID: <CAL02cgRAdt5PjYeQWwzTrP_TXUKr618Q8qMpz4VYNiyK0Du0yg@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary="001a11337688c7dbd9050851b96c"
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/mpuOtyuveoaQ7XRFx-bjAanpZlA
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: Thu, 20 Nov 2014 22:19:51 -0000
Thanks, Mike. That works for me. I cleared. On Wed, Nov 19, 2014 at 8:30 PM, Mike Jones <Michael.Jones@microsoft.com> wrote: > This resolution is incorporated in the -37 drafts. > > -- Mike > > > > *From:* jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Mike Jones > *Sent:* Wednesday, November 12, 2014 9:33 PM > *To:* Richard Barnes; Jim Schaad > *Cc:* jose-chairs@tools.ietf.org; The IESG; 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) > > > > Hi Richard and Jim, > > > > The sentence about integrity protecting header parameters has been changed > in my editor’s draft as follows: > > > > OLD: > > These Header Parameters MUST be integrity protected if the information > that they convey is to be utilized in a trust decision. > > NEW: > > These Header Parameters MUST be integrity protected if the information > that they convey is to be utilized in a trust decision; however, if the > only information used in the trust decision is a key, these parameters need > not be integrity protected, since changing them in a way that causes a > different key to be used will cause the validation to fail. > > > > Does this new language work for you? > > > > -- Mike > > > > *From:* Richard Barnes [mailto:rlb@ipv.sx <rlb@ipv.sx>] > *Sent:* Monday, November 10, 2014 4:04 PM > *To:* Mike Jones > *Cc:* Jim Schaad; 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, Nov 3, 2014 at 5:11 PM, Richard Barnes <rlb@ipv.sx> wrote: > > I've removed the formatting DISCUSS point, but would like to hear back > from Jim before clearing that one. > > --Richard > > > > 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. > > > > OK, Jim and I talked about this, and he's sort of convinced me. Namely, > that there is a security risk under the following conditions: > (1) the content of a key identifier (NOT the referenced key itself) is > used for security decisions > (2) the key identifier is not integrity protected > > (3) the relying party trusts multiple sources of keys with varying > security levels > > (4) the attacker is able to compromise provision an chosen key under a > trusted identifier > > > > Under these circumstances, an attacker can take a JWS that was signed with > an identity, and provision the key under the compromised identity, thus > asserting a signature under that identity. I think there's still a > loophole here [1], but this is getting squirrelly enough that it seems > easier to just say "MUST integrity protect" than to try to describe the > actual conditions. > > Could we at least try to be clearer about (1)? > > OLD: "These Header Parameters MUST be integrity protected if the > information that they convey is to be utilized in a trust decision." > NEW: "These Header Parameters MUST be integrity protected if the > information in the Header Parameter is to be utilized in a trust decision. > In cases where the referenced key is being used as the basis of the trust > decision, these headers MAY be used unprotected, since changing the key can > only cause the signature not to validate." > > > > Thanks, > > --Richard > > > > [1] If the attacker has compromised an identity in this way, then he can > provision whatever key he wants, and re-sign the message. > > > > > > > > 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. > > > > > > > > > >
- [jose] Richard Barnes' Discuss on draft-ietf-jose… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Jim Schaad
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Jim Schaad
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Jim Schaad
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Jim Schaad
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… ⌘ Matt Miller
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones