Re: [jose] Use of AES-HMAC algorithm

["Jim Schaad" <[e-mail]>]

Sorry for the delayed response - my mail server was not delivering mail
since I updated a certificate.

> -----Original Message-----
> From: Mike Jones [mailto:[e-mail]]
> Sent: Wednesday, March 27, 2013 5:21 PM
> To: Jim Schaad; [e-mail]
> Subject: RE: [jose] Use of AES-HMAC algorithm
> 
> 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.

Doubling was indeed a poor choice of words - but I think you are
understanding things.  We are going to go from a 256 bit key to a 768 bit
key - that is actually a tripling  of size for the A256CBC + HS512.  

> 
> 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).

I was actually looking at the case of wrapping the CMK and not wrapping
content when I wrote point 5.

Jim

> 
> 				-- 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