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

Dick Hardt <dick.hardt@gmail.com> Thu, 25 April 2013 23:01 UTC

Return-Path: <dick.hardt@gmail.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 11DB821F96B3 for <jose@ietfa.amsl.com>; Thu, 25 Apr 2013 16:01:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 9Hlc25TYuLSZ for <jose@ietfa.amsl.com>; Thu, 25 Apr 2013 16:01:27 -0700 (PDT)
Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by ietfa.amsl.com (Postfix) with ESMTP id A0A1621F8E4C for <jose@ietf.org>; Thu, 25 Apr 2013 16:01:27 -0700 (PDT)
Received: by mail-pd0-f176.google.com with SMTP id r11so2070680pdi.35 for <jose@ietf.org>; Thu, 25 Apr 2013 16:01:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=dEy8YhOGoeYJGlkvojNkB0vkjleNEkrZeOGJjaoG/uc=; b=Bej5LqFnZ3Sl3VSO+HWdFUWFPo0r2ozPOFUr/pJ0phnqVQQXkSnmxYMWlLNUSwuGvj KQqrDsnIeT1DSr9g7Oh0p5ZcXCzPE/xUCwb4NOEVgx8uRN/HnP9Snx+HkyNCwR5s3OPk mXzc50/VqHlLlrM6Yt5QoplQBskXUUTbH3HWMZp7+tGGkF0S0pNMFjywB6BjYOBfcca7 Nwt6KHPt2/xTwfnExJiAZALKi0skFj8dDBt2D6Z2cfnEfpfjz77AVVPCtvJ5YAG0ZTkc EpbpQqW5f7+JNtZ5AtWLqSgZ/C1mY0iPpMFB86X9CrmCaZs2xmYV8kcMEvW7LpmO8K5Y FENw==
X-Received: by 10.68.88.129 with SMTP id bg1mr55158510pbb.10.1366930887447; Thu, 25 Apr 2013 16:01:27 -0700 (PDT)
Received: from [10.0.0.80] (c-98-210-193-30.hsd1.ca.comcast.net. [98.210.193.30]) by mx.google.com with ESMTPSA id g8sm9902784pae.7.2013.04.25.16.01.24 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 16:01:25 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_217B81D3-FD19-41D7-A11B-506CF316A187"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Dick Hardt <dick.hardt@gmail.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943676C058B@TK5EX14MBXC283.redmond.corp.microsoft.com>
Date: Thu, 25 Apr 2013 16:01:22 -0700
Message-Id: <9335C55E-35A5-457E-960E-4138AA080ACC@gmail.com>
References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <B9EADFAC-382A-40C3-937C-C07E77777273@vigilsec.com> <4E1F6AAD24975D4BA5B1680429673943676C00E2@TK5EX14MBXC283.redmond.corp.microsoft.com> <4A22938F-958F-4648-933E-47AD443E21E3@vigilsec.com> <CAL02cgTkU8E7DN_btT0i1uZgGjq9TAeGZtu2sLdkUh+fX4jFkg@mail.gmail.com> <4E1F6AAD24975D4BA5B1680429673943676C058B@TK5EX14MBXC283.redmond.corp.microsoft.com>
To: Mike Jones <Michael.Jones@microsoft.com>
X-Mailer: Apple Mail (2.1503)
Cc: Richard Barnes <rlb@ipv.sx>, Russ Housley <housley@vigilsec.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 23:01:29 -0000

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 <Michael.Jones@microsoft.com> 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 [mailto:rlb@ipv.sx] 
> Sent: Thursday, April 25, 2013 2:46 PM
> To: Russ Housley
> Cc: Mike Jones; jose@ietf.org
> 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 <housley@vigilsec.com> 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:housley@vigilsec.com]
> > Sent: Thursday, April 25, 2013 10:31 AM
> > To: Mike Jones
> > Cc: jose@ietf.org
> > 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: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf
> >>> Of internet-drafts@ietf.org
> >>> Sent: Tuesday, April 23, 2013 5:29 PM
> >>> To: i-d-announce@ietf.org
> >>> Cc: 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-
> >>> 09
> >>>
> >>>
> >>> Internet-Drafts are also available by anonymous FTP at:
> >>> ftp://ftp.ietf.org/internet-drafts/
> >>>
> >>> _______________________________________________
> >>> jose mailing list
> >>> jose@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/jose
> >>
> >> _______________________________________________
> >> jose mailing list
> >> jose@ietf.org
> >> https://www.ietf.org/mailman/listinfo/jose
> >
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>  
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose