Re: [jose] Use of AES-HMAC algorithm

[Mike Jones <[e-mail]>]

Per your point 1, I don't think anyone was advocating doubling the key size.  The proposal in John's slides for issue #3 (http://trac.tools.ietf.org/wg/jose/trac/ticket/3) was to use a CMK that is the concatenation of the AES-CBC and HMAC-SHA-2 keys, as draft-mcgrew-aead-aes-hmac-sha2 does.  For instance, when using A128CBC with HS256, the key size would be 384 bits and when using A256CBC with HS512, the key size would be 768 bits.  This would multiply the current key sizes by 1.5, with the compensating benefit being the elimination of the use of the KDF.

Your point 2 wasn't part of issue #3.  This seems like an unnecessary change, particularly for GCM, where the IV is specified as a separate value from the ciphertext.

Your point 3 wasn't part of issue #3.  This seems like an unnecessary change, particularly for GCM, where the Authentication Tag is specified as a separate value from the ciphertext.

Per your point 4, after a conversation initiated by Joe Hildebrand and a call scheduled by Matt Miller, David McGrew has agreed refactor his draft so that the inputs and outputs are specified separately and independently from the RFC 5116 encoding of those values.  While RFC 5116 specifies a binary serialization for authenticated encryption algorithms, JWE specifies a textual serialization.  This refactoring would make it easy for JOSE to use the McGrew draft, since the computation would be specified separately from the serialization, should the working group choose to do so.

I suspect that once the refactoring is done, should the working group choose to use the McGrew algorithm, JWA could reference the appropriate sections of draft-mcgrew-aead-aes-hmac-sha2 and JWE could include an example computation for this algorithm, making it easy for developers to build.

Per your point 5, I think the term "key wrapping" is being used for two different things:  (1) Encrypting the ephemeral symmetric Content Master Key for a JWE and (2) encrypting a JWK or JWK Set containing symmetric and/or private key information and potentially other key attributes, enabling the encrypted JWK or JWK Set to be safely stored or transported.  It think it would clarify the discussions to keep these operations distinct.  I don't think anyone is proposing using AES-GCM or A128CBC+HS256 for (1), whereas they can already be used as part of (2) if the JWK is encrypted in a JWE, per Matt's draft.  Given the opinions voiced at the CFRG meeting that it's fine to use approved authenticated encryption algorithms to encrypt keys, I believe that there's already no problem with using these algorithms for (2).

				-- Mike

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Jim Schaad
Sent: Wednesday, March 27, 2013 3:21 PM
To: [e-mail]
Subject: [jose] Use of AES-HMAC algorithm

<chair>
After spending time looking at and thinking about how to resolve this issue since I was unable to do so at the last F2F meeting.  I have come up with the following set of issues that might need to be addressed as part of resolving this issue.

1.  Do we change from using KDC to having a double size key for the algorithm?  I think that there is probably a consensus that this should be done. 

2. Should IVs be prepended to the encrypted body as part of the encoding steps?  If so then this change should be universal. 

Doing so would eliminate one field from all of the encoding formats which should be considered a plus.
Doing so would force code writers to understand how large the IV is for all algorithms as the IV would no longer be a separate item.

3. Should Authentication Tags be appended to the encrypted body as part of the encoding steps?

Doing so would eliminate one field from all of the encoding formats which should be considered a plus.
Doing so would force code writers to understand how large the IV is for all algorithms as the IV would no longer be a separate item.
Doing so would force a re-organization for the multiple recipient case as either all recipient specific data would need to be excluded from the authentication step or all of the recipient data would need to be included for by all recipients.
Changing how the recipient info is process is going to give a performance benefit for sending encrypted items for multiple recipients.
The current strategy of a single IV and key pair with AES-GCM and different authentication data needs to have CFRG look at it.  I am worried that it might be a serious security flaw.

4. Should we reference the McGrew draft and provide text on how things are changed or should we "copy" the draft into our text?

5.  If we allow for the use of AES-GCM or AES-HMAC for doing key wrapping, does this change how we think about any of the above questions?

Allowing for AES-GCM for key wrapping has a benefit for hardware situations as only the encrypt and not the decrypt functions need to be placed in hardware.  However allowing for this key wrapping give a problem as there is no way to encode the three fields into the encrypted value unless with use either a JSON structure in this location or we do use the single appended binary output stream.  The first approach leads to an expansion of the field by double base64 encoding which is highly undesirable.

Jim


_______________________________________________
jose mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/jose