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

From: "Richard Barnes" <[email-masked]>
Date: Wed, 01 Oct 2014 20:36:59 -0700

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.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 3.3.
Why doesn't this example include the JSON encoding?

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.

Section 7.2.
The requirement that the "recipients" field MUST be present seems odd. 
What's the justification for this?

Appendix A seems kind of unnecessary given draft-ietf-jose-cookbook.

---

From: Mike Jones <[email-masked]>
Date: Sat, 11 Oct 2014 22:19:29 +0000

Thanks for your review, Richard.  Responses are inline below...

> -----Original Message-----
> From: jose [mailto:[email-masked]] On Behalf Of Richard Barnes
> Sent: Wednesday, October 01, 2014 8:37 PM
> To: The IESG
> Cc: [email-masked]; jose-
> [email-masked]; [email-masked]
> Subject: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-encryption-
> 33: (with DISCUSS and COMMENT)
> 
> 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.)
> 
> 
> 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.

Same answer as to your parallel question on JWS.

> 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.

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

				Thanks again,
				-- Mike

---

From: Richard Barnes <[email-masked]>
Date: Mon, 20 Oct 2014 12:21:22 -0400

On Sat, Oct 11, 2014 at 6:19 PM, Mike Jones <[email-masked]>
wrote:

> email
> concern,
> "recipients" array
> 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:
>
> Plus, there would be a third syntax if use of the "unprotected" parameter
> were not arbitrarily ruled out, as his proposal does:
>
> 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

> integrity-
> 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.
> 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.
>
> 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.
>

---

From: ⌘ Matt Miller <[email-masked]>
Date: Mon, 20 Oct 2014 10:53:57 -0600

On 10/20/14, 10:21 AM, Richard Barnes wrote:
> 
> 
> On Sat, Oct 11, 2014 at 6:19 PM, Mike Jones
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>> -----Original Message----- From: jose
>> [mailto:[email-masked]
> <mailto:[email-masked]>] On Behalf Of Richard Barnes
>> Sent: Wednesday, October 01, 2014 8:37 PM To: The IESG Cc:
>> [email-masked]
> <mailto:[email-masked]>; jose-
>> [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
>> 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
>> 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,
>> Section 7.2. I've had several implementors trying to use JWE in
>> the JSON
> serialization ask
>> 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
>> MUST be carried in the "header" field, and the "unprotected"
>> field
> MUST be
>> contain a "header" or "encrypted_key" field, and vice versa. """ 
> 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:
> 
> "recipients":[ {"header":<per-recipient unprotected header 1
> contents>, "encrypted_key":"<encrypted key 1 contents>"}], 
> "iv":"<initialization vector contents>", "ciphertext":"<ciphertext
> contents>", "tag":"<authentication tag contents>" }
> 
> and
> 
> "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:
> 
> "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.

>> Section 3.3. Why doesn't this example include the JSON encoding?
> 
>> 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.
> 
> 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 [email-masked] <mailto:[email-masked]> 
> Thanks again, -- Mike
> _______________________________________________ jose mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/jose
> 

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 21 Oct 2014 01:02:33 -0700

> optimizing for it seems like a good thing.

I've had a similar concern.  Multiple recipients is more the exception.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 21 Oct 2014 09:51:14 -0700

> From: jose [mailto:[email-masked]] On Behalf Of Martin Thomson
> Sent: Tuesday, October 21, 2014 1:03 AM
> To: ? Matt Miller
> Cc: [email-masked]; Richard Barnes; draft-ietf-jose-json-web-
> [email-masked]; Mike Jones; The IESG; [email-masked]
> Subject: Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-
> encryption-33: (with DISCUSS and COMMENT)
> 
> On 20 October 2014 09:53, ? Matt Miller <[email-masked]> wrote:

How much multiple recipients is the exception depends on the frequency of encrypting both for the recipient and for the sender or just for the recipient.  S/MIME always has at least two recipients for encryption because the sender gets a copy as well.  It is the case that single signing is the most common case in S/MIME.

Jim