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

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

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

On 10/20/14, 10:21 AM, Richard Barnes wrote:
> 
> 
> On Sat, Oct 11, 2014 at 6:19 PM, Mike Jones
> <[e-mail] <mailto:[e-mail]>>
> wrote:
> 
> Thanks for your review, Richard.  Responses are inline below...
> 
>> -----Original Message----- From: jose
>> [mailto:[e-mail]
> <mailto:[e-mail]>] On Behalf Of Richard Barnes
>> Sent: Wednesday, October 01, 2014 8:37 PM To: The IESG Cc:
>> [e-mail]
> <mailto:[e-mail]>; jose-
>> [e-mail] <mailto:[e-mail]>;
> [e-mail] <mailto:[e-mail]>
>> Subject: [jose] Richard Barnes' Discuss on
> draft-ietf-jose-json-web-encryption-
>> 33: (with DISCUSS and COMMENT)
>> 
>> Richard Barnes has entered the following ballot position for 
>> draft-ietf-jose-json-web-encryption-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-encryption/
>
>> 
> 
>> 
>> 
>> ----------------------------------------------------------------------
>
>> 
> 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 one
> remaining concern,
>> that should hopefully be easy to address.
>> 
>> Section 7.2. I've had several implementors trying to use JWE in
>> the JSON
> serialization ask
>> why it was necessary to include a "recipients" array in cases
> where there's only
>> one recipient.  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 JWE is encrypted for only one recipient, the
> "recipients" array
>> will contain a single object.  In such cases, the elements of
>> the
> "recipients" array
>> MAY be included at the top level of the JWE object.  If the
> generator of a JWE
>> chooses to use this representation then all unprotected header
> parameters
>> MUST be carried in the "header" field, and the "unprotected"
>> field
> MUST be
>> absent.  A JSON-formatted JWE that contains a "recipients" field
> MUST NOT
>> contain a "header" or "encrypted_key" field, and vice versa. """ 
>> This may also require some other changes where "recipients" is
> relied on, e.g., in
>> Section 9.
> 
> My response to this parallels that to the similar DISCUSS about
> JWS.
> 
> That said, I actually have marginally *more* concerns about this 
> proposal than the JWS one, because you're making an arbitrary
> choice between the multi-recipient "unprotected" parameter and the 
> per-recipient "header" parameter, and dictating that one be used
> in preference to another in the proposed case where "recipients"
> array is not present.  This adds an additional level of
> non-parallelism that isn't present in the JWS case.
> 
> For those following along, here are the two mostly equivalent 
> syntaxes that implementations would have to support in Richard's 
> proposal:
> 
> {"protected":"<integrity-protected shared header contents>", 
> "unprotected":<non-integrity-protected shared header contents>, 
> "recipients":[ {"header":<per-recipient unprotected header 1
> contents>, "encrypted_key":"<encrypted key 1 contents>"}], 
> "aad":"<additional authenticated data contents>", 
> "iv":"<initialization vector contents>", "ciphertext":"<ciphertext
> contents>", "tag":"<authentication tag contents>" }
> 
> and
> 
> {"protected":"<integrity-protected shared header contents>", 
> "header":<per-recipient unprotected header 1 contents>, 
> "encrypted_key":"<encrypted key 1 contents>", "aad":"<additional
> authenticated data contents>", "iv":"<initialization vector
> contents>", "ciphertext":"<ciphertext contents>", 
> "tag":"<authentication tag contents>" }
> 
> Plus, there would be a third syntax if use of the "unprotected" 
> parameter were not arbitrarily ruled out, as his proposal does:
> 
> {"protected":"<integrity-protected shared header contents>", 
> "unprotected":<non-integrity-protected shared header contents>, 
> "header":<per-recipient unprotected header 1 contents>, 
> "encrypted_key":"<encrypted key 1 contents>", "aad":"<additional
> authenticated data contents>", "iv":"<initialization vector
> contents>", "ciphertext":"<ciphertext contents>", 
> "tag":"<authentication tag contents>" }
> 
> During the Denver interim meeting in April 2013 and subsequent 
> working group decisions we all agreed to a specific syntax for the 
> JWE JSON Serialization.  We explicitly agreed to have a
> "recipients" array, since this serialization enables multiple
> recipients.  This syntax was incorporated in draft -11 in May 2013
> and has been stable since then.  Given you were an inventor of this
> syntax, Richard, I'm surprised to see you questioning it now, this
> late in the process.
> 
> I'll therefore ask you to withdraw this DISCUSS, since having 
> multiple syntaxes to represent the same semantics can only hurt 
> interoperability.
> 
> 
> FWIW, I'm not necessarily proposing multiple syntaxes.  I would be
> A-OK with requiring that single-recipient JWEs follow the
> simplified syntax.
> 
> My comments on the JWS thread about the multiple-recipient case
> reducing to the single-recipient case also apply here.  An
> implementor is going to have to build a single-recipient version
> *anyway*, since that's how the crypto works, so we might as well
> make the syntax match.
> 
> --Richard
> 

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-encrypt JSON serialization.
While multiple recipients is not quite as rare in encryption as it is
for signing, single-encrypt is still the more common usecase, and so
optimizing for it seems like a good thing.

> 
> 
> 
>> ----------------------------------------------------------------------
>
>> 
> COMMENT:
>> ----------------------------------------------------------------------
>
>> 
> 
>> Section 3.3. Why doesn't this example include the JSON encoding?
> 
> Same answer as to your parallel question on JWS.
> 
>> Section 4.1.3. "This Header Parameter MUST be integrity
>> protected" Why is this the case?  There is no security reason
>> that "zip" must be integrity- protected, and this requirement
>> isn't made for any other parameter.
> 
> ekr and others stated reasons for this when the compromise about 
> allowing some non-integrity-protected parameters was reached.  I 
> believe that they boiled down to ensuring that an attacker
> couldn't vary the contents of the plaintext by changing the "zip"
> parameter value as part of an attack.  Given the effectiveness of
> the CRIME attack against compression in SPDY since then, this
> advice seems all the more sound in retrospect.
> 
>> Section 7.2. The requirement that the "recipients" field MUST be
>> present seems odd. What's the justification for this?
> 
> Simplicity.  The structure of a JWE using the JSON Serialization
> is always the same that way, simplifying generators and parsers.
> If this weren't the case, they'd have to have a special case for
> the situation where the "recipients" array was omitted.
> 
>> Appendix A seems kind of unnecessary given
>> draft-ietf-jose-cookbook.
> 
> Developers have found the examples to be useful in practice.
> Having more in the cookbook just adds value, without detracting
> from the value of the examples in the JWE spec.
> 
>> _______________________________________________ jose mailing
>> list [e-mail] <mailto:[e-mail]> 
>> https://www.ietf.org/mailman/listinfo/jose
> 
> Thanks again, -- 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

iQEcBAEBCgAGBQJURT4lAAoJEDWi+S0W7cO1oUoH/icet/JldtOQKwedTjDu2bY0
J8y9Ahy9rVgN8TbDxoKhSt/GFu2CIIZ5BaNvcV7uViHlI6ip8gPhbhmcIyNiAOUj
ZEFk8Xu5UfOmWDYdxSfJy+R9I7mGJZDY5ikZGrMgp3Kz/JUNFv8Q3XHte4Dq2txJ
ELkRob7PSQnbcf2qycamGH9vEEeVKGMvz+UFU2jwcwF3ewi8kJFXSYbhP2bgSSfu
pgS3nURakFa7hpQjoFFDsrF0USFojlUfYUaqeiWwg4NRUrKwZ42hcgd3RRKj+TbY
t1AZq+9pLzNQ4bmJEC9rp3cBN/8bXxOT28CHNqeVZyPD7owKK+HAp3mValwA06k=
=J5EG
-----END PGP SIGNATURE-----