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

[Richard Barnes <[e-mail]>]

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 <[e-mail]>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:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Richard Barnes
> *Sent:* Thursday, April 25, 2013 2:51 PM
> *To:* John Bradley
> *Cc:* Mike Jones; Jim Schaad; [e-mail]
>
> *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 <[e-mail]> wrote:**
> **
>
>  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. ****
>
>  ** **
>
> 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.****
>
> 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)****
>
>  ** **
>
> 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 <[e-mail]> wrote:
> ****
>
>
>
> ****
>
> 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:[e-mail]]
> *Sent:* Thursday, April 25, 2013 11:14 AM
> *To:* Mike Jones
> *Cc:* Jim Schaad; [e-mail]
> *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.****
>
>  ****
>
> 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 <[e-mail]>
> 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****
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Jim Schaad
> Sent: Wednesday, April 24, 2013 9:07 PM
> To: Mike Jones
> Cc: [e-mail]
> Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt
>
> 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-0
> > 9
> >
> >
> > 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****
>
>  ****
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>
>  ** **
>