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

[Kathleen Moriarty <[e-mail]>]

Hi Richard,

Can you take a look at this and let me know what you think at this
point.  Can we resolve the discuss or do you have suggestions?

Thanks,
Kathleen

On Sat, Oct 25, 2014 at 2:34 AM, Mike Jones <[e-mail]> wrote:
> The simplified single-recipient JSON Serialization syntax has been added to
> draft -36.  Hopefully this will enable you to clear your remaining DISCUSS
> on this draft.
>
>
>
>                                                             Thanks again,
>
>                                                             -- Mike
>
>
>
> From: Richard Barnes [mailto:[e-mail]]
> Sent: Monday, October 20, 2014 9:21 AM
> To: Mike Jones
> Cc: The IESG; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [jose] Richard Barnes' Discuss on
> draft-ietf-jose-json-web-encryption-33: (with DISCUSS and COMMENT)
>
>
>
>
>
>
>
> On Sat, Oct 11, 2014 at 6:19 PM, Mike Jones <[e-mail]>
> wrote:
>
> Thanks for your review, Richard.  Responses are inline below...
>
>
>> -----Original Message-----
>> From: jose [mailto:[e-mail]] On Behalf Of Richard Barnes
>> Sent: Wednesday, October 01, 2014 8:37 PM
>> To: The IESG
>
>> Cc: [e-mail]; jose-
>> [e-mail]; [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
>
>
>
>
>
>> ----------------------------------------------------------------------
>> 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]
>> https://www.ietf.org/mailman/listinfo/jose
>
>                                 Thanks again,
>                                 -- Mike
>
>



-- 

Best regards,
Kathleen