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

Mike Jones <Michael.Jones@microsoft.com> Thu, 25 April 2013 22:46 UTC

Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD25621F9729 for <jose@ietfa.amsl.com>; Thu, 25 Apr 2013 15:46:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.948
X-Spam-Level:
X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsH6R7Oh6M-D for <jose@ietfa.amsl.com>; Thu, 25 Apr 2013 15:46:20 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA5D21F9726 for <jose@ietf.org>; Thu, 25 Apr 2013 15:46:19 -0700 (PDT)
Received: from BY2FFO11FD027.protection.gbl (10.1.15.201) by BY2FFO11HUB040.protection.gbl (10.1.14.161) with Microsoft SMTP Server (TLS) id 15.0.675.0; Thu, 25 Apr 2013 22:46:11 +0000
Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD027.mail.protection.outlook.com (10.1.15.216) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Thu, 25 Apr 2013 22:46:11 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.233]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Thu, 25 Apr 2013 22:46:02 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Richard Barnes <rlb@ipv.sx>, John Bradley <ve7jtb@ve7jtb.com>
Thread-Topic: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt
Thread-Index: AQHOQIL4trz81TOedUqxu9faqHUMmpjmU7yAgAAqctCAAMIPAIAAB4vggAAhhoCAABORgIAADu7A
Date: Thu, 25 Apr 2013 22:46:01 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943676C05E5@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676ACD2E@TK5EX14MBXC284.redmond.corp.microsoft.com> <CAL02cgSDhjpPaW-rjbRSa9+0MRnsZ1B_eEvAppVd__h69OMOsQ@mail.gmail.com> <4E1F6AAD24975D4BA5B1680429673943676C0128@TK5EX14MBXC283.redmond.corp.microsoft.com> <E394275C-34D7-47C9-874A-0FC0A08C83E9@ve7jtb.com> <CAL02cgRPVLyNa8OEwYhrnCWYopzvrUApixFqTjffsnFfKo5gsA@mail.gmail.com>
In-Reply-To: <CAL02cgRPVLyNa8OEwYhrnCWYopzvrUApixFqTjffsnFfKo5gsA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.75]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943676C05E5TK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704004)(377424002)(377454001)(24454001)(13464002)(199002)(189002)(63696002)(81342001)(76482001)(53806001)(79102001)(65816001)(74366001)(54316002)(15202345002)(44976003)(46102001)(47446002)(56816002)(55846006)(81542001)(80022001)(51856001)(59766001)(6806003)(50986001)(77982001)(47736001)(16236675002)(69226001)(512954001)(20776003)(564824004)(4396001)(47976001)(31966008)(16406001)(49866001)(56776001)(74502001)(33656001)(66066001)(74662001)(71186001)(54356001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB040; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0827D7ACB9
Cc: Jim Schaad <ietf@augustcellars.com>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Apr 2013 22:46:25 -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: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Thursday, April 25, 2013 2:51 PM
To: John Bradley
Cc: Mike Jones; Jim Schaad; jose@ietf.org
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 <ve7jtb@ve7jtb.com<mailto:ve7jtb@ve7jtb.com>> 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 <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> 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:rlb@ipv.sx<mailto:rlb@ipv.sx>]
Sent: Thursday, April 25, 2013 11:14 AM
To: Mike Jones
Cc: Jim Schaad; jose@ietf.org<mailto:jose@ietf.org>
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 <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> 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: jose-bounces@ietf.org<mailto:jose-bounces@ietf.org> [mailto:jose-bounces@ietf.org<mailto:jose-bounces@ietf.org>] On Behalf Of Jim Schaad
Sent: Wednesday, April 24, 2013 9:07 PM
To: Mike Jones
Cc: jose@ietf.org<mailto:jose@ietf.org>
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: jose-bounces@ietf.org<mailto:jose-bounces@ietf.org> [mailto:jose-bounces@ietf.org<mailto:jose-bounces@ietf.org>] On Behalf
> Of internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
> Sent: Tuesday, April 23, 2013 5:29 PM
> To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>
> Cc: jose@ietf.org<mailto:jose@ietf.org>
> 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
> jose@ietf.org<mailto:jose@ietf.org>
> https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
jose@ietf.org<mailto:jose@ietf.org>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org<mailto:jose@ietf.org>
https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
jose@ietf.org<mailto:jose@ietf.org>
https://www.ietf.org/mailman/listinfo/jose