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

[Mike Jones <[e-mail]>]

The resolutions proposed below have been applied to the -34 drafts.  I hope that you will choose to clear some or all of your DISCUSSes on that basis, however if you choose to leave some open for continued discussion by the working group, I understand that.  If so, please identify which ones you're choosing to have remain open, providing replies to my responses for those, if possible.

Note that an explicit reference to a JSON Serialization example was added to Section 3.3 as a result of your comment.

				Thanks again,
				-- Mike

> -----Original Message-----
> From: Mike Jones [mailto:[e-mail]]
> Sent: Saturday, October 11, 2014 2:15 PM
> To: Richard Barnes
> Cc: The IESG; [e-mail]; [e-mail]; draft-ietf-jose-json-
> [e-mail]
> Subject: RE: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-
> signature-33: (with DISCUSS and COMMENT)
> 
> > From: Richard Barnes [mailto:[e-mail]]
> > Sent: Friday, October 10, 2014 3:20 PM
> > To: Mike Jones
> > Cc: The IESG; [e-mail]; [e-mail];
> > [e-mail]
> > 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
> <[e-mail]> 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:[e-mail]] On Behalf Of Richard
> > > Barnes
> > > Sent: Wednesday, October 01, 2014 9:22 PM
> > > To: The IESG
> > > Cc: [e-mail]; [e-mail];
> > > draft-ietf-jose-json-web- [e-mail]
> > > Subject: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-
> 33:
> > > (with DISCUSS and COMMENT)
> > >
> > > Richard Barnes has entered the following ballot position for
> > > draft-ietf-jose-json-web-signature-33: Discuss
> > >
> > > When responding, please keep the subject line intact and reply to
> > > all email addresses included in the To and CC lines. (Feel free to
> > > cut this introductory paragraph, however.)
> > >
> > >
> > > Please refer to
> > > http://www.ietf.org/iesg/statement/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > > http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature/
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > --
> > > DISCUSS:
> > > --------------------------------------------------------------------
> > > --
> > >
> > > Overall, this document is in much more solid shape than when it began.
> > > Thanks to the WG for a lot of hard work.  I only have two remaining
> > > concerns, which should hopefully be easy to address.
> > >
> > > Section 7.2.
> > > I've had several implementers trying to use JWS in the JSON
> > > serialization ask why it was necessary to include a "signatures"
> > > array in cases where there's only one signer.  It seems like this is
> > > going to be a major barrier to deployment and re- use, so I would propose
> including the following text:
> > >
> > > """
> > > In cases where the JWS has been signed by only a single signer, the
> "signatures"
> > > array will contain a single object.  In such cases, the elements of
> > > the single "signatures" object MAY be included at the top level of
> > > the JWS object.  A JSON- formatted JWS that contains a "signatures"
> > > field MUST NOT contain a "protected", "header", or "signature" field, and
> vice versa.
> > > """
> > >
> > > This may also require some other changes where "signatures" is
> > > relied on, e.g., in Section 9 of the JWE spec.
> > This was previously proposed (I believe during the Denver interim meeting) and
> rejected by the working group because it complicates both producers and
> parsers by introducing an unnecessary special case.  Currently, by design,
> whether there are single or multiple signatures, the same syntax is used.  Your
> proposal would use a different syntax in the single signature case than in the
> multiple signature case.  This is likely to result in implementation bugs and
> inconsistencies.
> >
> > This assertion of complexity is bogus.  Have you implemented this syntax, or
> can you point me to someone who has, and has had problems?  I have
> implemented it and I'm asking for the simpler syntax.  I've gotten the same
> request from others, for JWE.
> 
> I'm not saying that anything is insurmountable.  I'm saying that having two
> equivalent syntaxes in the JSON Serialization for the same thing is going to make
> it more likely that some implementations won't correctly support both of them.
> For those following along, those two syntaxes would be:
> 
>   {
>    "payload":"<payload contents>",
>    "signatures":[
>     {"protected":"<integrity-protected header 1 contents>",
>      "header":<non-integrity-protected header 1 contents>,
>      "signature":"<signature 1 contents>"}]
>   }
> 
> and
> 
>   {
>    "payload":"<payload contents>",
>    "protected":"<integrity-protected header 1 contents>",
>    "header":<non-integrity-protected header 1 contents>,
>    "signature":"<signature 1 contents>"
>   }
> 
> Is your motivating use case a profile of the JSON Serialization in which multiple
> signatures aren't used or supported, and so for which the array notation would
> always be superfluous syntax?  Are you concerned that if this profile becomes
> the predominant use case, that some/many implementations wouldn't
> implement the more general multi-signature syntax (or would implement it
> incorrectly, since it would normally not ever be used or tested)?
> 
> I'd love to hear others in the working group chime in on this topic...
> 
> > > 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:
> >
> > """
> >    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.
> >
> > > --------------------------------------------------------------------
> > > --
> > > COMMENT:
> > > --------------------------------------------------------------------
> > > --
> > >
> > > Section 2.
> > > In the definition of "Unsecured JWS", it would be good to note that
> > > this requires "alg" == "none".
> >
> > OK
> >
> > > Section 3.3.
> > > Why doesn't this section have a JSON-encoded form as well?
> >
> > Because it's meant to be a simple introductory example to help people get
> their head around the concept - not a complete tutorial.  Other examples of
> JSON-encoded objects are found elsewhere in the document and lots of them
> are found in draft-ietf-jose-cookbook.
> >
> > > Appendix A.5.
> > > I would prefer if this example could be removed.  JWT is the only
> > > use case for Unsecured JWS right now, and there's already an example in
> that document.
> >
> > Mike> Given that it's important that implementers using them understand
> Unsecured JWSs, there is motivation to retain the example.  I'd be interested in
> what others in the working group think, given that there was substantial support
> for retaining this functionality when its removal was proposed.
> >
> > > Thanks for Appendix C.  FWIW, it has been implemented:
> > > http://dxr.mozilla.org/mozilla-central/source/dom/crypto/CryptoBuffe
> > > r.cpp#85
> >
> > You're welcome.
> >
> > > _______________________________________________
> > > jose mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/jose
> >
> >                                 Thanks again!
> >                                 -- Mike
> 
> 					-- Mike