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

[Richard Barnes <[e-mail]>]

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

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

+much_more_than_one




>
> Russ
>
>
> On Apr 25, 2013, at 3:09 PM, Mike Jones wrote:
>
> > 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:[e-mail]]
> > Sent: Thursday, April 25, 2013 10:31 AM
> > To: Mike Jones
> > Cc: [e-mail]
> > Subject: Re: [jose] I-D Action:
> draft-ietf-jose-json-web-encryption-09.txt
> >
> > 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
> >
> >
> > On Apr 25, 2013, at 12:07 AM, Jim Schaad wrote:
> >
> >> 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: [e-mail] [mailto:[e-mail]] On Behalf
> >>> Of [e-mail]
> >>> Sent: Tuesday, April 23, 2013 5:29 PM
> >>> To: [e-mail]
> >>> Cc: [e-mail]
> >>> Subject: [jose] I-D Action:
> >>> draft-ietf-jose-json-web-encryption-09.txt
> >>>
> >>>
> >>> 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/
> >>>
> >>> _______________________________________________
> >>> jose mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/jose
> >>
> >> _______________________________________________
> >> jose mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/jose
> >
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>