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

[⌘ Matt Miller <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/20/14, 10:15 AM, Richard Barnes wrote:
> 
> 
> On Sat, Oct 11, 2014 at 5:14 PM, Mike Jones 
> <[e-mail] <mailto:[e-mail]>> 
> wrote:
> 
>> From: Richard Barnes [mailto:[e-mail] <mailto:[e-mail]>] 
>> Sent: Friday, October 10, 2014 3:20 PM To: Mike Jones Cc: The 
>> IESG; [e-mail]
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; 
> [e-mail] 
> <mailto:[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] <mailto:[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]
> <mailto:[e-mail]>] On Behalf Of Richard Barnes
>>> Sent: Wednesday, October 01, 2014 9:22 PM To: The IESG Cc: 
>>> [e-mail]
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; draft-ietf-jose-json-web-
>>> [e-mail] <mailto:[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>" }
> 
> 
> It's worth noting that the multi-signer case reduces to the 
> single-signer case, e.g.:
> 
> <script> var JWS = get_jws(); if ("signatures" in JWS) { // i = 
> index of a signature we'll use JWS.protected = 
> JWS.signatures[i].protected JWS.header = JWS.signatures[i].header 
> JWS.signature = JWS.signatures[i].signature } else if (! 
> ("signature" in JWS) && (("protected" in JWS) || ("header" in 
> JWS))) { throw "malformed JWS"; } var result = 
> validate_single_signer_jws(JWS) </script>
> 
> Or copy "payload" up into each signature object.  Or iterate 
> through signatures and see which ones work.  Either way, you're 
> going to build this with a "verify single signature" primitive.
> 
> 
> 
> 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)?
> 
> 
> If you look at existing uses for signed objects (such as they are),
> single-signer is by far the dominant use case, so requiring the
> multiple signer notation is would almost always be superfluous 
> syntax.
> 
> I'm not all that concerned about support for multi-sig.  If 
> implementations care about it, it will get built.  And because of 
> the way this has been designed, it's easy to build once you've got 
> the single-signer version (see above).
> 
> 
> 
> I'd love to hear others in the working group chime in on this 
> topic...
> 

As I think I've said in previous discussions about the JSON
serialization, I can live with something verbose *BUT* would rather
like a lighter syntax for the single-sig JSON serialization.  It's by
far the most common usecase, so optimizing for it seems like a good thing.

>>> 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.
> 
> 
> It seems pretty clear to me :)  Everything involved in signature 
> verification is public, so anything the attacker could do by 
> tricking a third party into verifying he could just as well do 
> himself.  The only exception to this would be if the verification 
> were somehow a side-channel for something else happening on the 
> verifier's machine, which seems pretty outlandish.
> 
> 
> 
>> 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.
> 
> 
> I would note that issue #104 was closed without any discussion on 
> the list (AFAICT).  And that issue only related to "jku", so the 
> extension to all the other fields is unnecessary.  See my response 
> to Jim for why it's not necessary for "jku" either.
> 
> As far as issue #74, that appears to be about not using the URI as 
> an element of the trust decision unless the identity in the URI is
>  authenticated.  I read that as to mean that the subject of the URI
>  authenticated itself, e.g., using HTTPS server authentication.
> 
> 
> 
> 
>> 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/CryptoBuffer.cpp#85
>
>
> 
> 
>> You're welcome.
>> 
>>> _______________________________________________ jose mailing 
>>> list [e-mail] <mailto:[e-mail]> 
>>> https://www.ietf.org/mailman/listinfo/jose
>> 
>> Thanks again! -- Mike
> 
> -- Mike
> 
> 
> 
> 
> _______________________________________________ jose mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/jose
> 


- -- 
- - m&m

Matt Miller < [e-mail] >
Cisco Systems, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJURTwQAAoJEDWi+S0W7cO1bH0IALWtE7ZjYJgjtxeXtZCbHK1a
XZX1BcInXWEJa09tddnfU4kkHM26bcwO0KWUEcAgqaJGZawKFdB2SxpLnG3U1Cm3
LMzBtfYF1VhZgoh4YomuQkT8rflooy15PvlGBbbENjiVl/6KZiZ745lN86EEuXvI
+qX9Ltjf3VfupqMYafE79FP8yO+18O8EaYY66+njPQYm0kvTQQ1c6RJbAYlxjo4M
Zr5cmpTjEvS3wspHfE4fBiEp/kbjpGJ57jKSpKOK1hocibu6uMeEc9ImWWOgT6+5
u/ylFqkwMf8mvI3rLWIczJBSE/zl2G7cX/h+DJdustdaFjubYiMQH/YmMhWRcPw=
=sxXV
-----END PGP SIGNATURE-----