-----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
> <[email protected] <mailto:[email protected]>>
> wrote:
>
>> From: Richard Barnes [mailto:[email protected] <mailto:[email protected]>]
>> Sent: Friday, October 10, 2014 3:20 PM To: Mike Jones Cc: The
>> IESG; [email protected]
> <mailto:[email protected]>; [email protected]
> <mailto:[email protected]>;
> [email protected]
> <mailto:[email protected]>
>> 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
> <[email protected] <mailto:[email protected]>>
> 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:[email protected]
> <mailto:[email protected]>] On Behalf Of Richard Barnes
>>> Sent: Wednesday, October 01, 2014 9:22 PM To: The IESG Cc:
>>> [email protected]
> <mailto:[email protected]>; [email protected]
> <mailto:[email protected]>; draft-ietf-jose-json-web-
>>> [email protected] <mailto:[email protected]>
>>> 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 [email protected] <mailto:[email protected]>
>>> https://www.ietf.org/mailman/listinfo/jose
>>
>> Thanks again! -- Mike
>
> -- Mike
>
>
>
>
> _______________________________________________ jose mailing list
> [email protected] https://www.ietf.org/mailman/listinfo/jose
>
- --
- - m&m
Matt Miller < [email protected] >
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-----
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
