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

From: Richard Barnes <[email-masked]>
Date: Mon, 3 Nov 2014 22:11:17 -0500

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 <[email-masked]>
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.
>
>                                 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.
> > > > >
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 3 Nov 2014 22:12:42 -0500

> 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

---

From: Richard Barnes <[email-masked]>
Date: Mon, 10 Nov 2014 16:03:39 -1000

On Mon, Nov 3, 2014 at 5:11 PM, Richard Barnes <[email-masked]> wrote:

> I've removed the formatting DISCUSS point, but would like to hear back
> from Jim before clearing that one.
>
> --Richard
>
>> > > > > That's hand waving, not an attack scenario.  Allow me to
>> elaborate on
>> > > this:
>> > > > >
>> 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.
>> >
>> > 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.
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.

>> > > > arises is when two certificates have been issued for the same
>> public key,
>> > > > related comments about trust statements and trust decisions in
>> issue #74.
>> > > >

---

From: Mike Jones <[email-masked]>
Date: Thu, 13 Nov 2014 05:32:30 +0000

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:[email-masked]]
Sent: Monday, November 10, 2014 4:04 PM
To: Mike Jones
Cc: Jim Schaad; The IESG; [email-masked]; [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
> > > > > 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
> > > validity.  Unless the information is integrity-protected, the attacker
> > > > That's hand waving, not an attack scenario.  Allow me to elaborate on
> > this:
> > > >
> > > (vs. a cert) -- jwk, jku, and kid.  For any given signed object, there
> > > protect these headers, since there's no point to the attacker changing
> There is a difference between how a key is referenced and how a key reference is used in a trust decision.
>
> 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<http://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.
>
> If you've made the decision to trust both augustcellars.com<http://augustcellars.com> and augustwest.com<http://augustwest.com> to assert trusted keys, then you've trusted augustwest.com<http://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<http://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<http://augustcellars.com> signed the object when it didn't.
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
> > > >    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
> > > viable attack scenario.  It may or may not (knowing for sure is beyond
> > > these parameters to be integrity protected when used in a trust decision
> > > > With regard to the certificate identifiers ("x5u", "x5c", "x5t", and
> > > > "x5t#S256"),
> > > arises is when two certificates have been issued for the same public key,
> > > This is exceedingly rare in practice, and all current secure messaging
> > > systems get along fine without protection against this attack.  And it
> > > where the signer purposely presents different certificates to different
> > relying parties!
> > > appropriate.  It is only required for certain special situations using
> > certificates.
> > > Proposed revision:
> > > 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.
> > >
> > > that one of these certificates may be substituted for another. In such
> > > situations, the creator of a JWS object MUST integrity protect the "x5u",
> > > and the means by which it is obtained.  If I remember correctly, this was
> > one of those places.
> > > >

---

From: Mike Jones <[email-masked]>
Date: Thu, 20 Nov 2014 01:30:07 +0000

This resolution is incorporated in the -37 drafts.

                                                                -- Mike

From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, November 12, 2014 9:33 PM
To: Richard Barnes; Jim Schaad
Cc: [email-masked]; The IESG; [email-masked]; [email-masked]
Subject: Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)

Hi Richard and Jim,

OLD:

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Monday, November 10, 2014 4:04 PM
To: Mike Jones
Cc: Jim Schaad; The IESG; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)

Thanks,
--Richard

                                Thanks again,
                                -- Mike

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Nov 2014 17:19:45 -0500

Thanks, Mike.  That works for me.  I cleared.

On Wed, Nov 19, 2014 at 8:30 PM, Mike Jones <[email-masked]>
wrote:

> *From:* jose [mailto:[email-masked]] *On Behalf Of *Mike Jones
> *Sent:* Wednesday, November 12, 2014 9:33 PM
> *To:* Richard Barnes; Jim Schaad
> *Cc:* [email-masked]; The IESG; [email-masked];
> [email-masked]
>
> *Subject:* Re: [jose] Richard Barnes' Discuss on
> draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)
>
>
>
> Hi Richard and Jim,
>
>
>
> 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.
>
>
>
> *From:* Richard Barnes [mailto:[email-masked] <[email-masked]>]
> *Sent:* Monday, November 10, 2014 4:04 PM
> *To:* Mike Jones
> *Cc:* Jim Schaad; The IESG; [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: [jose] Richard Barnes' Discuss on
> draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)
>
>
>
>
>
>
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 20 Nov 2014 22:26:27 +0000

Thanks again for all the work you’ve put into these specs, Richard!

                                                                -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Thursday, November 20, 2014 2:20 PM
To: Mike Jones
Cc: Jim Schaad; [email-masked]; The IESG; [email-masked]; [email-masked]
Subject: Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)

On Wed, Nov 19, 2014 at 8:30 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                                -- Mike

From: jose [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mike Jones
Sent: Wednesday, November 12, 2014 9:33 PM
To: Richard Barnes; Jim Schaad
Cc: [email-masked]<mailto:[email-masked]>; The IESG; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Richard and Jim,

OLD:

                                                            -- Mike

Thanks,
--Richard

                                Thanks again,
                                -- Mike