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

John Bradley <ve7jtb@ve7jtb.com> Thu, 25 April 2013 23:09 UTC

Return-Path: <ve7jtb@ve7jtb.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 65DB021F91A3 for <jose@ietfa.amsl.com>; Thu, 25 Apr 2013 16:09:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level:
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, 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 13x6EsGpTH8D for <jose@ietfa.amsl.com>; Thu, 25 Apr 2013 16:09:10 -0700 (PDT)
Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C5C9521F96AB for <jose@ietf.org>; Thu, 25 Apr 2013 16:09:09 -0700 (PDT)
Received: by mail-ia0-f171.google.com with SMTP id r13so3090471iar.16 for <jose@ietf.org>; Thu, 25 Apr 2013 16:09:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=WsyecNnr8i8/8+cgCG66DoNmG0eUZoS9pRmhJIw5tVY=; b=fRPRIDZZKG7oWD628CQ/DhU+jeiKXzafRlQ2aPS0xIl2Cz+DCpP2FosShEib1G0okD /gPQ84SVTwd58tNAZRRRUAPzS/5AKMDvMx9zqpiSKRpjtdwmncBPP2COpVgDqGtzDbGH fUOP5upxyUPzmiF3B17WPUNPJ9tDlXjX0Kvd+x8ei+DP+y4oqYC1PclnlGPwPl9GroIm nkJU/b2+ISenAzJ1X7VCv/DVk3Lz3c3NnuSZ1J/9+QibnaYTrJtwU87NQd6dkR176AVw fqjnoKJ4a0z1i/DKHhxZD5J7yu03JeZWE3H84WpzQU+yX/3HrUjGI7FN2UGTz5VkMvIa XaMQ==
X-Received: by 10.50.153.232 with SMTP id vj8mr358274igb.2.1366931342620; Thu, 25 Apr 2013 16:09:02 -0700 (PDT)
Received: from [192.168.1.39] (190-20-37-138.baf.movistar.cl. [190.20.37.138]) by mx.google.com with ESMTPSA id 9sm126862igy.7.2013.04.25.16.08.59 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 16:09:01 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_17895419-E7E5-4D32-A088-9B0BE20BE54A"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <74C39AC5-0C6B-4DC1-A273-3996D97D90A9@vigilsec.com>
Date: Thu, 25 Apr 2013 20:08:25 -0300
Message-Id: <53360D8F-6AB2-4F8F-A73D-CDDD5FE2E00E@ve7jtb.com>
References: <20130424002901.19246.69134.idtracker@ietfa.amsl.com> <014201ce416a$82761a80$87624f80$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943676ACD2E@TK5EX14MBXC284.redmond.corp.microsoft.com> <74C39AC5-0C6B-4DC1-A273-3996D97D90A9@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>
X-Mailer: Apple Mail (2.1503)
X-Gm-Message-State: ALoCoQleaPdi+PjWvEIBP+X9MYALvIQ0JAYUc2f76pI24XOwnTm/GX8hHSl04kRuEYVCwHHg5rRZ
Cc: Mike Jones <Michael.Jones@microsoft.com>, 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:09:11 -0000

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.



On 2013-04-25, at 6:40 PM, Russ Housley <housley@vigilsec.com> wrote:

> 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
> 
> 
> On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones <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] On Behalf Of Jim Schaad
> Sent: Wednesday, April 24, 2013 9:07 PM
> To: Mike Jones
> Cc: 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] 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-0
> > 9
> >
> >
> > 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
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose