Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt

From: [email-masked]
Date: Tue, 23 Apr 2013 17:29:01 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Javascript Object Signing and Encryption Working Group of the IETF.

	Title           : JSON Web Encryption (JWE)
	Author(s)       : Michael B. Jones
                          Eric Rescorla
                          Joe Hildebrand
	Filename        : draft-ietf-jose-json-web-encryption-09.txt
	Pages           : 54
	Date            : 2013-04-23

Abstract:
   JSON Web Encryption (JWE) is a means of representing encrypted
   content using JavaScript Object Notation (JSON) data structures.
   Cryptographic algorithms and identifiers for use with this
   specification are described in the separate JSON Web Algorithms (JWA)
   specification.  Related digital signature and MAC capabilities are
   described in the separate JSON Web Signature (JWS) specification.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-jose-json-web-encryption-09

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 24 Apr 2013 21:07:19 -0700

Mike,

AES GCM MUST NOT be used when using the JWE JSON Serialization for
   multiple recipients, since this would result in the same
   Initialization Vector and Plaintext values being used for multiple
   GCM encryptions.

I doubt your co-authors would agree with this.
I doubt the working group with agree with this.
I know that at least one co-chair does not agree with this
I can predict that the AD and IESG along with the security directorate would
crucify me if I allowed this to stand in the document..

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, April 23, 2013 5:29 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt
> 
> 
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Mike Jones <[email-masked]>
Date: Thu, 25 Apr 2013 06:48:27 +0000

Jim - I am surprised that you would say that my co-authors Eric Rescorla or Joe Hildebrand or the working group would advocate using AES GCM in a way that would result in severe security vulnerabilities - in particular, allowing attackers to obtain the XOR of the messages to multiple recipients encrypted using GCM - a vulnerability identified by the CFRG.

Not stating this in the document would seem to me to be highly irresponsible, given the brittleness of GCM in this regard, as identified by the CRFG.  As I said to Richard Barnes over dinner last night, while unpleasant, and possibly surprising to those who aren't familiar to how GCM actually works, as an editor, I viewed including the statement that "AES GCM MUST NOT be used when using the JWE JSON Serialization for multiple recipients, since this would result in the same Initialization Vector and Plaintext values being used for multiple GCM encryptions" as necessary, and "truth in advertising".

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Wednesday, April 24, 2013 9:07 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt

Mike,

I doubt your co-authors would agree with this.
I doubt the working group with agree with this.
I know that at least one co-chair does not agree with this I can predict that the AD and IESG along with the security directorate would crucify me if I allowed this to stand in the document..

Jim

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of [email-masked]

---

From: Russ Housley <[email-masked]>
Date: Thu, 25 Apr 2013 13:30:36 -0400

Mike:

Like Jim, I cannot support this statement: AES GCM MUST NOT be used when using the JWE JSON Serialization for multiple recipients

All recipients ought to be performing decryption and integrity checking with the same GCM key.  The manner in which they obtain that key may be different (key transport: decrypt the GCM key with the recipient's private key, key agreement: agreement of a pairwise KEK and then unwrapping the GCM key with the KEK, pre-shared KEK: unwrapping the GCM key with the already known KEK, etc).

Russ

---

From: Richard Barnes <[email-masked]>
Date: Thu, 25 Apr 2013 14:13:48 -0400

Mike,

Your facts are right, but your conclusions are wrong.

We have three mutually incompatible goals here:
1. GCM
2. Efficient encoding for multiple recipients
3. Header integrity

We can have any two of these, but not all three.  If we try to do all three
(JWE-08), then we end up with the vulnerability identified in the CFRG
thread.  So we need to choose which one to get rid of.

Getting rid of GCM is clearly not the right answer, as evidenced by the
reaction in this thread.  There are clear, concrete use reasons to support
multiple recipients, but not for header integrity.  And header integrity
can be "polyfilled" with an optional feature, for those who are willing to
break the multiple recipient case.  Clearly, header integrity is the
weakest link here.

JWE-09 is the reductio ad absurdum of header integrity.  Let's do the
logical thing and stop the absurdity.

--Richard

On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones <[email-masked]>wrote:

> Jim - I am surprised that you would say that my co-authors Eric Rescorla
> or Joe Hildebrand or the working group would advocate using AES GCM in a
> way that would result in severe security vulnerabilities - in particular,
> allowing attackers to obtain the XOR of the messages to multiple recipients
> encrypted using GCM - a vulnerability identified by the CFRG.
>
> Not stating this in the document would seem to me to be highly
> irresponsible, given the brittleness of GCM in this regard, as identified
> by the CRFG.  As I said to Richard Barnes over dinner last night, while
> unpleasant, and possibly surprising to those who aren't familiar to how GCM
> actually works, as an editor, I viewed including the statement that "AES
> GCM MUST NOT be used when using the JWE JSON Serialization for multiple
> recipients, since this would result in the same Initialization Vector and
> Plaintext values being used for multiple GCM encryptions" as necessary, and
> "truth in advertising".
>
>                                 -- Mike
>
> Jim Schaad
> I know that at least one co-chair does not agree with this I can predict
> that the AD and IESG along with the security directorate would crucify me
> if I allowed this to stand in the document..
>
> Jim
>
>
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 25 Apr 2013 19:09:40 +0000

Hi Russ,

I agree that enabling GCM to be safely used in the multiple recipients case would be highly desirable.  It is currently prohibited because if the recipients share a common key and initialization vector (IV) but use different AAD values, this results in the identified vulnerability.  One possible solution that continues integrity protecting the headers but enables the safe use of GCM was identified off-list by John Bradley.
 
That solution is to have each recipient always use the same key, IV, and AAD values.  This could be accomplished by including all the header values in a single combined AAD value, rather than having the integrity protection for each recipient's headers be independent.

This change could be done in a manner that doesn't affect the computation for the single recipients case.  Given the upcoming interim JOSE meeting next week, and given the (understandable) strong negative reaction to the unusability of GCM with the current multiple recipients processing rules, I'll plan on quickly producing a draft -10 that changes the processing rules in the manner described above, so that idea can be concretely considered by the working group next week.

Just so people are clear on the properties on the new processing rules - this would mean that the integrity computations for each recipients would no longer be independent.  The only downside of this (which could be an upside in some ways) is that it would no longer be possible to add recipients over time without performing a new encryption computation with a new CEK and IV.

				Cheers,
				-- Mike

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Thursday, April 25, 2013 10:31 AM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt

Mike:

Russ

On Apr 25, 2013, at 12:07 AM, Jim Schaad wrote:

> I know that at least one co-chair does not agree with this I can 
> predict that the AD and IESG along with the security directorate would 
>> Subject: [jose] I-D Action: 
>> draft-ietf-jose-json-web-encryption-09.txt
>> 
>>

---

From: Mike Jones <[email-masked]>
Date: Thu, 25 Apr 2013 19:14:30 +0000

Hi Richard,

Actually, there are four goals in play:

1.  GCM
2.  Efficient encoding for multiple recipients
3.  Header integrity protection
4.  Independent protection of each recipient's headers

Per my response to Russ, by giving up 4, we can achieve 1, 2, and 3.  (Credit goes to John Bradley for this solution.)

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Thursday, April 25, 2013 11:14 AM
To: Mike Jones
Cc: Jim Schaad; [email-masked]
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt

Mike,

We can have any two of these, but not all three.  If we try to do all three (JWE-08), then we end up with the vulnerability identified in the CFRG thread.  So we need to choose which one to get rid of.

Getting rid of GCM is clearly not the right answer, as evidenced by the reaction in this thread.  There are clear, concrete use reasons to support multiple recipients, but not for header integrity.  And header integrity can be "polyfilled" with an optional feature, for those who are willing to break the multiple recipient case.  Clearly, header integrity is the weakest link here.

JWE-09 is the reductio ad absurdum of header integrity.  Let's do the logical thing and stop the absurdity.

--Richard

On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Jim - I am surprised that you would say that my co-authors Eric Rescorla or Joe Hildebrand or the working group would advocate using AES GCM in a way that would result in severe security vulnerabilities - in particular, allowing attackers to obtain the XOR of the messages to multiple recipients encrypted using GCM - a vulnerability identified by the CFRG.

                                -- Mike

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jim Schaad
Sent: Wednesday, April 24, 2013 9:07 PM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt

Mike,

Jim

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> Of [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: John Bradley <[email-masked]>
Date: Thu, 25 Apr 2013 17:40:47 -0300

For multiple recipients using GCM with a single CEK and IV we can logically have 0 AAD segments or 1 AAD segment.

That is just the reality of the situation.  

One possible solution is to the GCM issue is to have 1 AAD segment containing the envelope information for all recipients.
I understand for people wanting 0 AAD segments that will not be there first choice.

The downside of this is that you can't incrementally add recipients, they all need to be known upfront to include the info in the AAD.

What I don't know is if there is really any compelling use-case for incremental addition of recipients without re-encrypting (changing the IV atleast)

John B.
 .  

On 2013-04-25, at 4:14 PM, Mike Jones <[email-masked]> wrote:

> 4.  Independent protection of each recipient’s headers
>  
> On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones <[email-masked]> wrote:

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 25 Apr 2013 13:55:08 -0700

Mike,

There are two possible reasons for me to make the statement.

First - that it is unacceptable that we are making the statement that the
use of AES-GCM - the current standard AEAD algorithm - cannot be used with
this or

Second - that the statement of non-use is insufficiently broad to cover the
needed cases.  The correct statement would be that 

This JSON serialization format re-uses the same IV/Key pair for multiple
recipients.  This means that the algorithm used MUST NOT have any issues
with IV/Key pair re-use.  It is known at this time this will eliminate the
ability to use any algorithm which uses counter mode for encryption.  Among
the AEAD algorithms that use counter mode for their encryption mode is
AES-GCM and thus AES-GCM MUST NOT be used with multiple recipients.

It is noted that almost all (if not all) of the current crop of AEAD
algorithms are using CTR mode and thus cannot be used with this
specification.

Jim

> From: Mike Jones [mailto:[email-masked]]
> Sent: Wednesday, April 24, 2013 11:48 PM
> To: Jim Schaad
> Cc: [email-masked]
> Subject: RE: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt
> 
or Joe
> Hildebrand or the working group would advocate using AES GCM in a way that
> would result in severe security vulnerabilities - in particular, allowing
> attackers to obtain the XOR of the messages to multiple recipients
encrypted
> using GCM - a vulnerability identified by the CFRG.
> 
irresponsible,
> given the brittleness of GCM in this regard, as identified by the CRFG.
As I said
> to Richard Barnes over dinner last night, while unpleasant, and possibly
> surprising to those who aren't familiar to how GCM actually works, as an
> editor, I viewed including the statement that "AES GCM MUST NOT be used
> when using the JWE JSON Serialization for multiple recipients, since this
would
> result in the same Initialization Vector and Plaintext values being used
for
> multiple GCM encryptions" as necessary, and "truth in advertising".
> 
> 				-- Mike
> 
Jim
> Schaad
that the
> AD and IESG along with the security directorate would crucify me if I
allowed
> this to stand in the document..
> 
> Jim
> 
> 
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 25 Apr 2013 17:40:16 -0400

Mike:

The same message encrypted with different GCM keys is a problem, but that is not what ought to be going on here.  I tried to explain that in my previous message.  The same GCM key is delivered to multiple recipients, perhaps using different key management techniques.  Since the originator and all of the recipients use exactly the same key stream, this XOR concern does not arise.

Russ

                                -- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Wednesday, April 24, 2013 9:07 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt

Mike,

Jim

---

From: Russ Housley <[email-masked]>
Date: Thu, 25 Apr 2013 17:45:20 -0400

Mike:

If the header is protected with the AAD mechanism in GCM, then it must cover exactly the same bits for all recipients.

I do not see the need for JOSE header integrity.  I have said this in the past.  I'm saying it again....

Russ

---

From: Richard Barnes <[email-masked]>
Date: Thu, 25 Apr 2013 17:46:10 -0400

On Thu, Apr 25, 2013 at 5:45 PM, Russ Housley <[email-masked]> wrote:

> Mike:
>
> If the header is protected with the AAD mechanism in GCM, then it must
> cover exactly the same bits for all recipients.
>

+much_more_than_one

> > I agree that enabling GCM to be safely used in the multiple recipients
> case would be highly desirable.  It is currently prohibited because if the
> recipients share a common key and initialization vector (IV) but use
> different AAD values, this results in the identified vulnerability.  One
> possible solution that continues integrity protecting the headers but
> enables the safe use of GCM was identified off-list by John Bradley.
> >
> > That solution is to have each recipient always use the same key, IV, and
> AAD values.  This could be accomplished by including all the header values
> in a single combined AAD value, rather than having the integrity protection
> for each recipient's headers be independent.
> >
> > This change could be done in a manner that doesn't affect the
> computation for the single recipients case.  Given the upcoming interim
> JOSE meeting next week, and given the (understandable) strong negative
> reaction to the unusability of GCM with the current multiple recipients
> processing rules, I'll plan on quickly producing a draft -10 that changes
> the processing rules in the manner described above, so that idea can be
> concretely considered by the working group next week.
> >
> > Just so people are clear on the properties on the new processing rules -
> this would mean that the integrity computations for each recipients would
> no longer be independent.  The only downside of this (which could be an
> upside in some ways) is that it would no longer be possible to add
> recipients over time without performing a new encryption computation with a
> new CEK and IV.
> >
> >                               Cheers,
> >                               -- Mike
> >
> > Subject: Re: [jose] I-D Action:
> > Like Jim, I cannot support this statement: AES GCM MUST NOT be used when
> using the JWE JSON Serialization for multiple recipients
> >
> > All recipients ought to be performing decryption and integrity checking
> with the same GCM key.  The manner in which they obtain that key may be
> different (key transport: decrypt the GCM key with the recipient's private
> key, key agreement: agreement of a pairwise KEK and then unwrapping the GCM
> key with the KEK, pre-shared KEK: unwrapping the GCM key with the already
> known KEK, etc).
> >
> > Russ
> >
> >

---

From: Richard Barnes <[email-masked]>
Date: Thu, 25 Apr 2013 17:50:49 -0400

On Thu, Apr 25, 2013 at 4:40 PM, John Bradley <[email-masked]> wrote:

> For multiple recipients using GCM with a single CEK and IV we can
> logically have 0 AAD segments or 1 AAD segment.
>

I would also note that taking the JOSE overhead out of the AAD segment
frees it up for the application to use.

> One possible solution is to the GCM issue is to have 1 AAD segment
> containing the envelope information for all recipients.
> The downside of this is that you can't incrementally add recipients, they
> all need to be known upfront to include the info in the AAD.
>
> What I don't know is if there is really any compelling use-case for
> incremental addition of recipients without re-encrypting (changing the IV
> atleast)
>

The XMPP use case is precisely this.  When the sender encrypts the message,
it doesn't know the set of public keys that it's sending it to.

So the only other possible alternative is taking the per-recipient info out
of the integrity check.  But if we're going to do that, we might as well go
all the way and get rid of the integrity check altogether.   Applications
that want to integrity protect information can put it in the AAD segment on
their own.

--Richard

> Hi Richard,****
> Actually, there are four goals in play:****
>
> 1.  GCM****
> 2.  Efficient encoding for multiple recipients****
> 3.  Header integrity protection****
> 4.  Independent protection of each recipient’s headers****
>
> Per my response to Russ, by giving up 4, we can achieve 1, 2, and 3.
> (Credit goes to John Bradley for this solution.)****
>
>                                                             -- Mike****
>
> *From:* Richard Barnes [mailto:[email-masked]]
> *Sent:* Thursday, April 25, 2013 11:14 AM
> *To:* Mike Jones
> *Cc:* Jim Schaad; [email-masked]
> *Subject:* Re: [jose] I-D Action:
> draft-ietf-jose-json-web-encryption-09.txt****
> ** **
> Mike, ****
> ** **
> Your facts are right, but your conclusions are wrong.****
> ** **
> We have three mutually incompatible goals here:****
> 1. GCM****
> 2. Efficient encoding for multiple recipients****
> 3. Header integrity****
> ** **
> We can have any two of these, but not all three.  If we try to do all
> three (JWE-08), then we end up with the vulnerability identified in the
> CFRG thread.  So we need to choose which one to get rid of.****
> ** **
> weakest link here.****
> ** **
> logical thing and stop the absurdity.****
> ** **
> --Richard****
> ** **
> ** **
>
> ** **
> On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones <[email-masked]>
> wrote:****
>                                 -- Mike****
> https://www.ietf.org/mailman/listinfo/jose****
> ** **

---

From: Richard Barnes <[email-masked]>
Date: Thu, 25 Apr 2013 17:56:33 -0400

On Thu, Apr 25, 2013 at 3:09 PM, Mike Jones <[email-masked]>wrote:

> This change could be done in a manner that doesn't affect the computation
> for the single recipients case.  Given the upcoming interim JOSE meeting
> next week, and given the (understandable) strong negative reaction to the
> unusability of GCM with the current multiple recipients processing rules,
> I'll plan on quickly producing a draft -10 that changes the processing
> rules in the manner described above, so that idea can be concretely
> considered by the working group next week.
>

As I said to John, that is not an acceptable solution because it breaks the
XMPP use case.  The minimum sensible change is to remove the per-recipient
info from the integrity check.

--Richard

---

From: Matt Miller <[email-masked]>
Date: Thu, 25 Apr 2013 16:02:19 -0600

> info from the integrity check.

It is not clear to me how John's suggestion utterly breaks the XMPP use case, unless you have this alternate-reality version of XMPP-E2E you've not yet told me about (-:

The current XMPP document already separates per-recipient info from the actual protected content.

- m&m

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

---

From: Richard Barnes <[email-masked]>
Date: Thu, 25 Apr 2013 18:10:07 -0400

On Thu, Apr 25, 2013 at 6:02 PM, Matt Miller <[email-masked]> wrote:

> > On Thu, Apr 25, 2013 at 3:09 PM, Mike Jones <[email-masked]
> >wrote:
> >
> >> Hi Russ,
> >>
> computation
> It is not clear to me how John's suggestion utterly breaks the XMPP use
> case, unless you have this alternate-reality version of XMPP-E2E you've not
> yet told me about (-:
>

I reject your reality and substitute my own! [1]

In my preferred reality, XMPP E2E doesn't have to do the alg=dir hack that
it does now.  The base format will support multiple recipients cleanly
enough to support the XMPP case as well.

In any case, preventing incremental addition of recipients is an arbitrary
and capricious restriction in the name of a non-existent security benefit.

--Richard

[1] http://www.youtube.com/watch?v=W8qcccZy03s

---

From: Mike Jones <[email-masked]>
Date: Thu, 25 Apr 2013 22:28:10 +0000

The same message isn't being encrypted with multiple GCM keys.  It is only encrypted with one key.  Indeed, the proposed change that I discussed in my earlier message to you that would enable the use of GCM with multiple recipients would only encrypt the plaintext once.  The originator and all recipients use exactly the key stream - just as you said.

                                                                -- Mike

From: Russ Housley [mailto:[email-masked]]
Sent: Thursday, April 25, 2013 2:40 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt

Mike:

Russ

                                -- Mike

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jim Schaad
Sent: Wednesday, April 24, 2013 9:07 PM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt

Mike,

Jim

---

From: Mike Jones <[email-masked]>
Date: Thu, 25 Apr 2013 22:42:46 +0000

As background on the decision to integrity protect the headers - this didn't come out of a vacuum.  The JWT designers sought out Ben Laurie's advice in 2010 and he'd suggested that the best thing would be to protect everything.  Indeed, Ben restated exactly the same position in a CRFG discussion on the topic earlier this month, writing "Why even discuss these? What is wrong with the answer "all parameters should be protected"?".

Ben's not the only one who believes that it's appropriate to protect the metadata.  For instance, the abstract of RFC 6211 "Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute" begins "The Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution attacks".  Like RFC 6211 does for CMS, some would also like to prevent those attacks for JOSE.

                                                                Best wishes,

                                                                -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Thursday, April 25, 2013 2:46 PM
To: Russ Housley
Cc: Mike Jones; [email-masked]
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt

On Thu, Apr 25, 2013 at 5:45 PM, Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:
Mike:

+much_more_than_one

Russ

On Apr 25, 2013, at 3:09 PM, Mike Jones wrote:

> From: Russ Housley [mailto:[email-masked]<mailto:[email-masked]>]

---

From: Mike Jones <[email-masked]>
Date: Thu, 25 Apr 2013 22:46:01 +0000

Applications are now free to add their own AAD information to the JWE header, now that not-understood header parameters must be ignored.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Thursday, April 25, 2013 2:51 PM
To: John Bradley
Cc: Mike Jones; Jim Schaad; [email-masked]
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt

On Thu, Apr 25, 2013 at 4:40 PM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
For multiple recipients using GCM with a single CEK and IV we can logically have 0 AAD segments or 1 AAD segment.

I would also note that taking the JOSE overhead out of the AAD segment frees it up for the application to use.

The XMPP use case is precisely this.  When the sender encrypts the message, it doesn't know the set of public keys that it's sending it to.

So the only other possible alternative is taking the per-recipient info out of the integrity check.  But if we're going to do that, we might as well go all the way and get rid of the integrity check altogether.   Applications that want to integrity protect information can put it in the AAD segment on their own.

--Richard

John B.
 .

On 2013-04-25, at 4:14 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

Hi Richard,

1.  GCM

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, April 25, 2013 11:14 AM
To: Mike Jones
Cc: Jim Schaad; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt

Mike,

--Richard

                                -- Mike

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jim Schaad
Sent: Wednesday, April 24, 2013 9:07 PM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt

Mike,

Jim

---

From: Dick Hardt <[email-masked]>
Date: Thu, 25 Apr 2013 16:01:22 -0700

FWIW, as an implementor, I would like the headers protected. I don't require multiple recipients.

On Apr 25, 2013, at 3:42 PM, Mike Jones <[email-masked]> wrote:

> As background on the decision to integrity protect the headers – this didn’t come out of a vacuum.  The JWT designers sought out Ben Laurie’s advice in 2010 and he’d suggested that the best thing would be to protect everything.  Indeed, Ben restated exactly the same position in a CRFG discussion on the topic earlier this month, writing “Why even discuss these? What is wrong with the answer "all parameters should be protected"?”.
>  
> Ben’s not the only one who believes that it’s appropriate to protect the metadata.  For instance, the abstract of RFC 6211 “Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute” begins “The Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution attacks”.  Like RFC 6211 does for CMS, some would also like to prevent those attacks for JOSE.
>  
>                                                                 Best wishes,
>                                                                 -- Mike
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 25 Apr 2013 19:05:00 -0400

On Thu, Apr 25, 2013 at 6:42 PM, Mike Jones <[email-masked]>wrote:

>  As background on the decision to integrity protect the headers – this
> didn’t come out of a vacuum.  The JWT designers sought out Ben Laurie’s
> advice in 2010 and he’d suggested that the best thing would be to protect
> everything.  Indeed, Ben restated exactly the same position in a CRFG
> discussion on the topic earlier this month, writing “Why even discuss
> these? What is wrong with the answer "all parameters should be protected"?
> ”.
>
You should also note that I answered that question, and Ben backed off
significantly from his initial position.  There were also several other
commenters on the CFRG thread, who did not see utility in mandatory header
protection.

> I agree! There should be an *option* for integrity-protecting parameters,
in the limited cases where such protection is necessary.  It is not
necessary with PKCS#1 v1.5 signatures, since the signature algorithm
encodes an OID for the hash algorithm.  It is not necessary for JWE.  I
would be happy to discuss the shape of such an option at the interim next
week.

--Richard

> ****
>                                                                 Best
> wishes,****
>                                                                 -- Mike***
> *
> *Sent:* Thursday, April 25, 2013 2:46 PM
> *To:* Russ Housley
> *Cc:* Mike Jones; [email-masked]
>
> On Thu, Apr 25, 2013 at 5:45 PM, Russ Housley <[email-masked]>
> wrote:****
>
> Mike:
>
> I do not see the need for JOSE header integrity.  I have said this in the
> past.  I'm saying it again....****
>
>  ** **
>
> +much_more_than_one****
>
> ** **
>
> ** **
>
>  ****
>
>
> Russ****
>
>
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 25 Apr 2013 19:06:12 -0400

Yes, if the application is willing to accept the horrendous inefficiency of
double-base64 encoding.

Again, arbitrary and capricious restriction in the name of a non-existent
security benefit.

--Richard

On Thu, Apr 25, 2013 at 6:46 PM, Mike Jones <[email-masked]>wrote:

>  Applications are now free to add their own AAD information to the JWE
> header, now that not-understood header parameters must be ignored.****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Richard Barnes
> *Sent:* Thursday, April 25, 2013 2:51 PM
> *To:* John Bradley
> *Cc:* Mike Jones; Jim Schaad; [email-masked]
>
> On Thu, Apr 25, 2013 at 4:40 PM, John Bradley <[email-masked]> wrote:**
> **
>
> logically have 0 AAD segments or 1 AAD segment.****
>
> ** **
>
> That is just the reality of the situation. ****
>
>  ** **
>
> frees it up for the application to use.****
>
> ** **
>
>  ****
>
> containing the envelope information for all recipients.****
>
> I understand for people wanting 0 AAD segments that will not be there
> first choice.****
>
> ** **
>
> all need to be known upfront to include the info in the AAD.****
>
> ** **
>
> atleast)****
> The XMPP use case is precisely this.  When the sender encrypts the
> message, it doesn't know the set of public keys that it's sending it to.**
> **
>
> ** **
>
> So the only other possible alternative is taking the per-recipient info
> out of the integrity check.  But if we're going to do that, we might as
> well go all the way and get rid of the integrity check altogether.
> Applications that want to integrity protect information can put it in the
> AAD segment on their own. ****
>
> ** **
>
> --Richard****
>
> ** **
>
> ** **
>
>  ****
>
>  ** **
>
> John B.****
>
>  .  ****
>
> ** **
>

---

From: John Bradley <[email-masked]>
Date: Thu, 25 Apr 2013 20:08:25 -0300

I think there were two issues identified.

1.  Encrypting multiple plain texts with the same key and IV is defiantly a bad thing., and it is relatively easy to see why.
2.  Encrypting the same plaintext multiple times with the same IV and CMK but changing the AAD.   The problem with this is slightly less clear.   There will be multiple tags generated one for each different AAD.  To produce the tag you encrypt the final hash value with the block is xored with the IV block encrypted with the CMK.  

 I don't personally know of an attack that can exploit having multiple tags xored with the same value.   My take on it from Mc Grew's comment on the list was it is probably not a good thing.   I think Mike and I both took from the conversation that producing multiple tag values that are xord with the same encrypted value is not something that was recommended.

If I have that wrong now would be a good time to say that the practice is OK.   

Regards
John B.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 25 Apr 2013 19:11:36 -0400

This is not complicated.  There are some algorithms that will REQUIRE the
integrity option, and others that will not.  We can clearly specify in JWA.

The complication imposed by mandatory header integrity is far greater.

--Richard

On Thu, Apr 25, 2013 at 7:07 PM, Mike Jones <[email-masked]>wrote:

>  Options just complicate things, and give developers additional
> opportunities to make the wrong choices.****
>
> ** **
>
> *Sent:* Thursday, April 25, 2013 4:05 PM
> *To:* Mike Jones
> *Cc:* Russ Housley; [email-masked]
>
> On Thu, Apr 25, 2013 at 6:42 PM, Mike Jones <[email-masked]>
> wrote:****
>
> ”.****
> protection.****
>  Ben’s not the only one who believes that it’s appropriate to protect the metadata.  For instance, the abstract of RFC 6211 “Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute” begins “The Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution attacks”.  Like RFC 6211 does for CMS, some would also like to prevent those attacks for JOSE.****
>
>   I agree! There should be an *option* for integrity-protecting
> parameters, in the limited cases where such protection is necessary.  It is
> not necessary with PKCS#1 v1.5 signatures, since the signature algorithm
> week. ****
> *Cc:* Mike Jones; [email-masked]****
>
>

---

From: John Bradley <[email-masked]>
Date: Thu, 25 Apr 2013 20:13:23 -0300

I agree with Matt.   I don't think there is anything in the XMPP use case that would break if the envelope is integrity protected.  
I think there is only a single envelope anyway as I understand it.   

John B.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 25 Apr 2013 19:16:37 -0400

Again, this is because Matt has hacked around the current system to remove
per-recipient data from integrity protection.  And the fact that you're OK
with that would mean that you would be OK with removing per-recipient data
from integrity protection in general, if you were to be logically
consistent ;)

--Richard

On Thu, Apr 25, 2013 at 7:13 PM, John Bradley <[email-masked]> wrote:

> I agree with Matt.   I don't think there is anything in the XMPP use case
> that would break if the envelope is integrity protected.

---

From: Mike Jones <[email-masked]>
Date: Thu, 25 Apr 2013 23:07:30 +0000

Options just complicate things, and give developers additional opportunities to make the wrong choices.

From: Richard Barnes [mailto:[email-masked]]
Sent: Thursday, April 25, 2013 4:05 PM
To: Mike Jones
Cc: Russ Housley; [email-masked]
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt

On Thu, Apr 25, 2013 at 6:42 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

As background on the decision to integrity protect the headers - this didn't come out of a vacuum.  The JWT designers sought out Ben Laurie's advice in 2010 and he'd suggested that the best thing would be to protect everything.  Indeed, Ben restated exactly the same position in a CRFG discussion on the topic earlier this month, writing "Why even discuss these? What is wrong with the answer "all parameters should be protected"?".
You should also note that I answered that question, and Ben backed off significantly from his initial position.  There were also several other commenters on the CFRG thread, who did not see utility in mandatory header protection.

Ben's not the only one who believes that it's appropriate to protect the metadata.  For instance, the abstract of RFC 6211 "Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute" begins "The Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution attacks".  Like RFC 6211 does for CMS, some would also like to prevent those attacks for JOSE.
I agree! There should be an *option* for integrity-protecting parameters, in the limited cases where such protection is necessary.  It is not necessary with PKCS#1 v1.5 signatures, since the signature algorithm encodes an OID for the hash algorithm.  It is not necessary for JWE.  I would be happy to discuss the shape of such an option at the interim next week.

--Richard

                                                                Best wishes,

                                                                -- Mike

From: Richard Barnes [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, April 25, 2013 2:46 PM
To: Russ Housley
Cc: Mike Jones; [email-masked]<mailto:[email-masked]>

+much_more_than_one

Russ

---

From: John Bradley <[email-masked]>
Date: Thu, 25 Apr 2013 20:26:15 -0300

I suspect you are overstating the case:)

It is hard to have per endpoint recipient information in the header when the sender doesn't know what the endpoints that are going to receive the JWE are before it sends it.

I would prefer to avoid using XMPP as a football for this.

There is probably a better use case someplace that would show how a sender knowing beforehand the information for multiple recipients would encrypt the same plain text to all of them.   Mostly what I would like to understand is if there is a real requirement for incremental encryption to new recipients after the fact using the same CMK & IV, or can the CMK & IV change for additional recipients.

John B.

On 2013-04-25, at 8:16 PM, Richard Barnes <[email-masked]> wrote:

> Again, this is because Matt has hacked around the current system to remove per-recipient data from integrity protection.  And the fact that you're OK with that would mean that you would be OK with removing per-recipient data from integrity protection in general, if you were to be logically consistent ;)
> 
> --Richard
> 
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 25 Apr 2013 23:47:48 +0000

Not all AAD data will be binary.  For instance, if it's already JSON object, no base64url encoding would be necessary.

From: Richard Barnes [mailto:[email-masked]]
Sent: Thursday, April 25, 2013 4:06 PM
To: Mike Jones
Cc: John Bradley; Jim Schaad; [email-masked]
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt

Yes, if the application is willing to accept the horrendous inefficiency of double-base64 encoding.

Again, arbitrary and capricious restriction in the name of a non-existent security benefit.

--Richard

On Thu, Apr 25, 2013 at 6:46 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Applications are now free to add their own AAD information to the JWE header, now that not-understood header parameters must be ignored.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Richard Barnes
Sent: Thursday, April 25, 2013 2:51 PM
To: John Bradley
Cc: Mike Jones; Jim Schaad; [email-masked]<mailto:[email-masked]>

--Richard

John B.
 .

Hi Richard,

1.  GCM

                                                            -- Mike

Mike,

--Richard

                                -- Mike

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jim Schaad
Sent: Wednesday, April 24, 2013 9:07 PM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt

Mike,

Jim

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 26 Apr 2013 17:32:39 +1000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
> Sent: Friday, 26 April 2013 9:08 AM
>
> ...

Rename "IV" to "Nonce" (as it is labelled in RFC 5116 "Authenticated Encryption" for instance) and the problem is clearer: the point of a nonce is that it is only used once (per key).

JOSE cannot keep its current multiple recipient mode as it breaks the general model of an AEAD algorithm. RFC 5116 section 2.1: "Each nonce provided to distinct invocations of the Authenticated Encryption operation MUST be distinct, for any particular value of the key, unless each and every nonce is zero-length". Regardless of whether or not using GCM with same-nonce-and-plaintext-different-AAD is ok, it will not be ok with other AEAD algs, such as SIV [RFC 5297]. Considering any authentication tag to be part of the ciphertext (JOSE issue #11) would avoid this sort of crypto craziness.

--
James Manger