Return-Path: 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 2D51B21F87CF for ; Mon, 12 Nov 2012 17:36:52 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzGhY1q5ORx3 for ; Mon, 12 Nov 2012 17:36:50 -0800 (PST) Received: from col0-omc4-s3.col0.hotmail.com (col0-omc4-s3.col0.hotmail.com [65.55.34.205]) by ietfa.amsl.com (Postfix) with ESMTP id 533BF21F8788 for ; Mon, 12 Nov 2012 17:36:50 -0800 (PST) Received: from COL401-EAS436 ([65.55.34.199]) by col0-omc4-s3.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Nov 2012 17:36:49 -0800 X-Originating-IP: [32.173.214.130] X-EIP: [RksFGqcBip46A6Ga1yMGpVuM3wAb7cN8] X-Originating-Email: [michael_b_jones@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_c18d8d59-6f64-4747-8f62-240c572c3402_" MIME-Version: 1.0 From: Michael Jones Date: Mon, 12 Nov 2012 17:36:33 -0800 To: "David McGrew (mcgrew)" , "cfrg@irtf.org" , "jose@ietf.org" X-OriginalArrivalTime: 13 Nov 2012 01:36:49.0811 (UTC) FILETIME=[59D90E30:01CDC13F] Cc: "Paterson, Kenny" Subject: Re: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 01:36:52 -0000 --_c18d8d59-6f64-4747-8f62-240c572c3402_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Believe me=2C if there were out of the box AEAD algorithm implementations a= vailable in most crypto libraries=2C I'd be eager to use them. As it is th= ough=2C all we can count on really being there are AES CBC and SHA-2. The J= WE algs are intended to be as easy to securely and interoperably implement = with those building blocks as possible. Remember that implementers will be building these algorithms from those par= ts themselves. A key JOSE goal is making that prospect both approachable an= d attractive. That's my primary motivation in all of these (very useful) d= iscussions. I'm sure that's a goal we all share. Cheers=2C -- Mike Sent from my Windows Phone ________________________________ From: David McGrew (mcgrew) Sent: 11/12/2012 3:20 PM To: Michael Jones=3B cfrg@irtf.org=3B jose@ietf.org Cc: Paterson=2C Kenny Subject: Re: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA=2C v= ersion 01 From: Michael Jones > Date: Monday=2C November 12=2C 2012 3:25 PM To: Cisco Employee >=2C "cfrg@irt= f.org" >=2C "jose= @ietf.org" > Subject: RE: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA=2C v= ersion 01 OK=2C I admit that the way I phrased my request may not be exactly in line = with the way the =E2=80=9CAEAD=E2=80=9D terminology is used. I can correct= that. That=E2=80=99s syntax. I was using =E2=80=9CAEAD=E2=80=9D as a shor= thand for the working group=E2=80=99s decision to use only authenticated en= cryption algorithms =E2=80=93 not to mean the particular combined represent= ation of those parameters apparently specified in the AEAD draft. I will c= orrect the terminology usage in the next revision of the JOSE specification= s. The semantic point remains that it=E2=80=99s cleaner and more flexible to h= ave the Key=2C the Plaintext=2C IV=2C and =E2=80=9Cadditional authenticated= data=E2=80=9D parameters all be separate inputs and the Ciphertext and =E2= =80=9Cauthentication tag=E2=80=9D all be separate outputs. In JOSE=E2=80=99= s particular use case=2C that would be a significantly better match and eas= ier for implementers to use. JOSE already has a way of combining the inputs and outputs that=E2=80=99s i= nherent to its representation=2C and it doesn=E2=80=99t match the one you= =E2=80=99ve specified. GCM=2C CTR=2C and the current JOSE-specified algori= thms are a great fit for this=2C as they can directly use that representati= on. The AEAD pattern you cite requires disassembly of the components of th= e AEAD-specific representation to be able to use the combinations already p= resent in the JOSE representations and then reassembly at decryption time. = That=E2=80=99s just more work for implementers=2C and it=E2=80=99s not sem= antically necessary work. One could just as easily argue that the unnecessary work comes from the fac= t that draft-ietf-jose-json-web-algorithms-07 defines its own AEAD algorith= ms=2C which do not use the RFC 5116 interface. The draft confusingly refe= rences that RFC after it defines AEAD=2C but then does something different.= If the plan is really going to be for the JOSE WG to define its own AEAD= algorithms that are incompatible (which I hope is not the case)=2C the dif= ferences and motivation deserve to be documented. The motivation for 5116 incorporating the authentication data into the ciph= ertext was to simplify the interface and move more of the crypto details un= der the crypto interface. These are still valid motivations=2C though at = this point the most important reason to use the interface is to avoid gratu= itous incompatibility. Other protocols have not had any trouble in using t= he 5116 interface=3B See RFC 5288 (TLSv1.2) Section 6.2.3.3=2C RFC 5647 (SS= H GCM)=2C or draft-ietf-avtcore-srtp-aes-gcm=2C for instance. Are you open to specifying versions of your algorithms that don=E2=80=99t r= equire a particular combination method for the parameters=2C but instead le= ave the combination up to the use case? I=E2=80=99m fine with you also spe= cifying a specific combination method as an optional feature of the specifi= cation. But it shouldn=E2=80=99t be part of the algorithm definition=2C ju= st like it isn=E2=80=99t for GCM. I am not dogmatically opposed to other interfaces=2C but the best solution = here is for JOSE to actually use the 5116 interface=2C like this: X.Y. Authenticated Encryption This section defines the specifics of encrypting the JWE Plaintext Using the Authenticated Encryption with Associated Data (AEAD) as defined in RFC 5116. The authenticated encryption operation has four inputs=2C as follows: The secret key is the CMK. The associated data is the bytes of the ASCII representation of the co= ncatenation of the Encoded JWE Header=2C a period ('.') character=2C the Encoded JWE Encrypted Key=2C a second period character ('.')=2C and the Encoded JW= E Initialization Vector=2C per Section 5 of the JWE specification. The plaintext =2C which contains the data to be encrypted and authenticated. A nonce N=2C with a length of either 0 or 96 bits. If the length is zero=2C the nonce is omitted. Otherwise=2C the nonce is as described in Section 3 of RFC 5116. There is a single output=2C the Ciphertext. The "enc" header parameter values are set as follows: "enc" Algorithm ----------------------------------------------------------------------- "A128GCM" AEAD_AES_128_GCM "A256GCM" AEAD_AES_256_GCM "A128CHS" AEAD_AES_128_CBC_HMAC_SHA_256 "A256CHS" AEAD_AES_256_CBC_HMAC_SHA_512 "A128SIV" AEAD_AES_SIV_CMAC_256 "A256SIV" AEAD_AES_SIV_CMAC_384 See for the references corresponding to these symbolic names. If we want to make actual progress on crypto interfaces=2C the thing that w= ould be worth doing is defining a simpler interface that moves the nonce de= tails into the ciphertext (and thus away from the user). Moving the authe= ntication data out of the ciphertext would be movement in the wrong directi= on=2C in my opinion. David Best wishes=2C -- Mike From: David McGrew (mcgrew) [mailto:mcgrew@cisco.com] Sent: Monday=2C November 12=2C 2012 11:43 AM To: Mike Jones=3B cfrg@irtf.org=3B jose@ietf.org Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA=2C v= ersion 01 Hi Mike=2C From: Mike Jones > Date: Monday=2C November 12=2C 2012 1:55 PM To: Cisco Employee >=2C "cfrg@irt= f.org" >=2C "jose= @ietf.org" > Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA=2C v= ersion 01 As background=2C if there was a version of this spec that did not assume th= at the parameters would be concatenated together in a specific way=2C but l= eft them as independent inputs and outputs=2C as AES GCM and AES CTR do=2C = it would be a better match for JOSE=E2=80=99s use case. I believe that what you are referring to is the inclusion of the authentica= tion tag in the authenticated ciphertext. This is not just a property of = draft-mcgrew-aead-aes-cbc-hmac-sha2=3B it is a feature of all 19 of the AEA= D algorithms that have been defined so far. For comparison=2C draft-mcgre= w-aead-aes-cbc-hmac-sha2 says The AEAD Ciphertext consists of the string S=2C with the string T appended to it. This Ciphertext is returned as the output of the AEAD encryption operation. Where S is the ciphertext and T is the authentication tag. RFC 5116 says "The AEAD_AES_128_GCM ciphertext is fo= rmed by appending the authentication tag provided as an output to the GCM encryption operation to the ciphertext that is output by that operation." David -- Mike ________________________________ From: mcgrew@cisco.com To: cfrg@irtf.org=3B jose@ietf.org Date: Mon=2C 12 Nov 2012 18:20:57 +0000 CC: Kenny.Paterson@rhul.ac.uk Subject: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA=2C versi= on 01 Hi=2C There is a new version of "Authenticated Encryption with AES-CBC and HMAC-S= HA"=2C and I would appreciate your review. It is online at <= https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/?inclu= de_text=3D1%3e> The diff between the current and the previous version is = available at This draft has been proposed for use in the JOSE WG =2C where its adop= tion would allow the working group to omit "raw" unauthenticated encryption= =2C e.g. AES-CBC=2C and only include authenticated encryption. Thus I am = asking for your help in making John Foley generated test cases that correspond to the current version of t= he draft=2C but I didn't include these in the draft because I did not yet g= et confirmation from a second independent implementation. With hope=2C th= ere will not be any need for any normative changes=2C and I will include th= ese after I get confirmation. Thanks=2C David _______________________________________________ jose mailing list jose@ietf= .org https://www.ietf.org/mailman/listinfo/jose --_c18d8d59-6f64-4747-8f62-240c572c3402_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Beli= eve me=2C if there were out of the box AEAD algorithm implementations avail= able in most crypto libraries=2C I'd be eager to use them. =3B As it is= though=2C all we can count on really being there are AES CBC and SHA-2. The JWE algs are intended to be as easy to securely and= interoperably implement with those building blocks as possible.

Remember that implementers will be building these algorithms from those par= ts themselves. A key JOSE goal is making that prospect both approachable an= d attractive. =3B That's my primary motivation in all of these (very us= eful) discussions. =3B I'm sure that's a goal we all share.

Cheers=2C
-- Mike

Sent from my Windows Phone
From: David McGrew (mcgrew)
Sent: 11/12/2012 3:20 PM
To: Michael Jones=3B cfrg@irtf.org=3B jose@ietf.org
Cc: Paterson=2C Kenny
Subject: Re: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA=2C versi= on 01



From: Michael Jones <=3Bmichael_b_jones@hotmail.com>= =3B
Date: Monday=2C November 12=2C 2012= 3:25 PM
To: Cisco Employee <=3Bmcgrew@cisco.com>=3B=2C "=3Bcfrg@irtf.org"=3B <=3Bcfrg@irtf.org>=3B=2C "=3Bjose@ietf.org"=3B <=3Bjose@ietf.org>=3B
Subject: RE: [jose] Authenticated E= ncryption with AES-CBC and HMAC-SHA=2C version 01


O= K=2C I admit that the way I phrased my request may not be exactly in line w= ith the way the =E2=80=9CAEAD=E2=80=9D terminology is used. =3B I can correct that. That=E2=80=99s syntax. =3B = I was using =E2=80=9CAEAD=E2=80=9D as a shorthand for the working gr= oup=E2=80=99s decision to use only authenticated encryption algorithms =E2= =80=93 not to mean the particular combined representation of those paramete= rs apparently specified in the AEAD draft. =3B I will correc= t the terminology usage in the next revision of the JOSE specifications.


T= he semantic point remains that it=E2=80=99s cleaner and more flexible to ha= ve the Key=2C the Plaintext=2C IV=2C and =E2=80=9Cadditional authenticated data=E2=80=9D parameters all be separate inputs and the Ciphertext and =E2= =80=9Cauthentication tag=E2=80=9D all be separate outputs.=  =3BIn JOSE=E2=80=99s particular use case=2C that would be a sig= nificantly better match and easier for implementers to use.



J= OSE already has a way of combining the inputs and outputs that=E2=80=99s in= herent to its representation=2C and it doesn=E2=80=99t match the one you=E2=80=99ve specified. =3B GCM=2C CTR=2C an= d the current JOSE-specified algorithms are a great fit for this=2C as they= can directly use that representation. =3B The AEAD pattern you cite requires disassembly of the components of = the AEAD-specific representation to be able to use the combinations already= present in the JOSE representations and then reassembly at decryption time= . =3B That=E2=80=99s just more work for implementers=2C and it=E2=80=99s n= ot semantically necessary work.

One could just as easily argue that =3Bthe unnecessary w= ork comes from the fact that =3Bdraft-ietf-jose-json-web-algorithms-07 = defines its own AEAD algorithms=2C which do not use the RFC 5116 interface.  =3B The draft confusingly references that RFC after i= t defines AEAD=2C but then does something different.  =3B If the plan i= s really going to be for the JOSE WG to define its own AEAD algorithms that= are incompatible (which I hope is not the case)=2C the differences and motivation deserve to be documented.  =3B

The motivation for 5116 incorporating the authentication dat= a into the ciphertext was to simplify the interface and move more of the cr= ypto details under the crypto interface.  =3B These are still valid motivations=2C though at this point the most important rea= son to use the interface is to avoid gratuitous incompatibility.  =3BOt= her protocols have not had any trouble in using the 5116 interface=3B See R= FC 5288 (TLSv1.2) Section 6.2.3.3=2C RFC 5647 (SSH GCM)=2C or =3Bdraft-ietf-avtcore-srtp-aes-gcm=2C for instance. &n= bsp=3B


A= re you open to specifying versions of your algorithms that don=E2=80=99t re= quire a particular combination method for the parameters=2C but instead leave the combination up to the use case?&nbs= p=3B I=E2=80=99m fine with you also specifying a specific combinatio= n method as an optional feature of the specification.  =3BBut it shouldn=E2=80=99t be part of the alg= orithm definition=2C just like it isn=E2=80=99t for GCM.

I am not dogmatically opposed to other interfaces=2C but the= best solution here is for JOSE to actually use the 5116 interface=2C like = this:

X.Y. = Authenticated Encryption

 = =3B  =3BThis section defines the specifics of encrypting the JWE Plaint= ext
 = =3B  =3BUsing the Authenticated Encryption with Associated Data (AEAD)<= /font>
 = =3B  =3Bas defined in RFC 5116.  =3B =3BThe= authenticated encryption operation =3B
 =3B  =3Bhas four inputs=2C as follows:

 =3B  =3B  =3BThe secret key is the CMK.

 =3B  =3B  =3BThe associated data is the bytes of the= ASCII representation of the concatenation of
 =3B  =3B  =3Bthe Encoded JWE Header=2C a period ('.') cha= racter=2C the Encoded JWE
 =3B  =3B  =3BEncrypted Key=2C a second period character (= '.')=2C and the Encoded JWE
 =3B  =3B  =3BInitialization Vector=2C per Section 5 of th= e JWE specification.
 =3B  =3B  =3B The plaintext =2C which contains the data t= o be encrypted and
 =3B  =3B  =3B authenticated.

 =3B  =3B  =3B A nonce N=2C with a length of either 0= or 96 bits.  =3B If the length
 = =3B  =3B  =3B is zero=2C the nonce is omitted.  =3BOtherwise=2C= the nonce
 = =3B  =3B  =3B is as described in Section 3 of RFC 5116.  =3B&nb= sp=3B

 =3B  =3BThere is a single output=2C the Ciphertext.  =3B<= /div>

 =3B  =3BThe "=3Benc"=3B header =3B= parameter values are set as follows:

 =3B  =3B "=3Benc"=3B  =3B  =3B  =3B &n= bsp=3B  =3B  =3B  =3B  =3B  =3BAlgorithm  =3B  = =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B=  =3B  =3B =3B
 = =3B  =3B --------------------------------------------------------------= ---------
 =3B  =3B =3B"=3BA128GCM"=3B  =3B=  =3B =3BAEAD_AES_128_GCM  =3B  =3B  =3B  =3B  = =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B=  =3B  =3B  =3B  =3B
 =3B  =3B "=3BA256GCM"=3B  =3B  =3B AEAD_AE= S_256_GCM  =3B  =3B  =3B  =3B  =3B  =3B  =3B &n= bsp=3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B  = =3B  =3B =3B
 =3B  =3B  =3B"=3BA128CHS"=3B  =3B  =3B=  =3BAEAD_AES_128_CBC_HMAC_SHA_256  =3B  =3B
 =3B  =3B  =3B"=3BA25= 6CHS"=3B  =3B  =3B  =3BAEAD_AES_256_CBC_HMAC_SHA_512  = =3B
 =3B  =3B  =3B "=3BA128SIV"=3B  =3B  =3B &= nbsp=3BAEAD_AES_SIV_CMAC_256
 =3B  =3B  =3B "=3BA256SIV"=3B  =3B  =3B &= nbsp=3BAEAD_AES_SIV_CMAC_384

 = =3B  =3B  =3Breferences corresponding to =3Bthese sym= bolic names.  =3B

If we= want to make actual progress on crypto interfaces=2C the thing that would = be worth doing is defining a simpler interface that moves the nonce details= into the ciphertext (and thus away from the user).  =3B Moving the authentication data out of the ciphertext w= ould be movement in the wrong direction=2C in my opinion.  =3B =3B<= /font>

David


<= span style=3D""> =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B Best wishes=2C

<= span style=3D""> =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B -- Mike



From: David McGrew (mcgre= w) [mailto:mcgrew@cisco.com]
Sent: Monday=2C November 12=2C 2012 11:43 AM
To: Mike Jones=3B cfrg@irtf.org= =3B jose@ietf.org
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-S= HA=2C version 01


Hi Mike=2C


From: Mike Jones <=3BMichael.Jones@microsoft.com>=3B
Date: Monday=2C November 12=2C 2012 1:55 PM
To: Cisco Employee <=3Bmcgrew@cisco.com>=3B=2C "=3Bcfrg@irtf.org"= =3B <=3Bcfrg@irt= f.org>=3B=2C "=3Bjose@ietf= .org"=3B <=3Bjose@ietf.org>=3B
Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-S= HA=2C version 01


A= s background=2C if there was a version of this spec that did not assume tha= t the parameters would be concatenated together in a specific way=2C but left them as independent inputs and outputs=2C as AE= S GCM and AES CTR do=2C it would be a better match for JOSE=E2=80=99s use c= ase.

 =3B

I believe th= at what you are referring to is the inclusion of the authentication tag in = the authenticated ciphertext.  =3B This is not just a property of draft-mcgrew-aead-aes-cbc-hmac-sha2=3B it is a feature = of all 19 of the AEAD algorithms that have been defined so far.  =3B Fo= r comparison=2C =3Bdraft-mcgrew-aead-aes-cbc-hmac-sha2 says =3B


 =3B &nb= sp=3B  =3B  =3BThe AEAD Ciphertext consists of the string S=2C with= the string T

 =3B &nb= sp=3B  =3B  =3Bappended to it.  =3BThis Ciphertext is returned = as the output of the

 =3B &nb= sp=3B  =3B  =3BAEAD encryption operation.

 =3B

Where S is t= he ciphertext and T is the authentication tag.  =3B =3BRFC 5116 say= s


 =3B &nb= sp=3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B  = =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B=  =3B"=3BThe AEAD_AES_128_GCM ciphertext is formed by

 =3B &nb= sp=3Bappending the authentication tag provided as an output to the GCM

 =3B &nb= sp=3Bencryption operation to the ciphertext that is output by that

 =3B &nb= sp=3Boperation."=3B


David=


&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B -- Mike


From: mcgrew@cisco.com
To: cfrg@irtf.org=3B jose@ietf.org
Date: Mon=2C 12 Nov 2012 18:20:57 +=3B0000
CC: Kenny.Paterson@rhul.ac.uk<= /a>
Subject: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA=2C versi= on 01

Hi=2C
This draft has been proposed for use in the JOSE WG <=3Bhttp://= datatracker.ietf.org/wg/jose/>=3B =3B=2C where its adoption would allow the working group to omit "=3Braw"=3B unauthenticated = encryption=2C e.g. AES-CBC=2C and only include authenticated encryption. &n= bsp=3B Thus I am asking for your help in making =3B
John Foley generated test cases that correspond to the curre= nt version of the draft=2C but I didn't include these in the draft because = I did not yet get confirmation from a second independent implementation.  =3B With hope=2C there will not be any need for any n= ormative changes=2C and I will include these after I get confirmation. &nbs= p=3B
Thanks=2C
David

_______________________________________________ jose mailing list jose@ietf.org ht= tps://www.ietf.org/mailman/listinfo/jose
--_c18d8d59-6f64-4747-8f62-240c572c3402_--