Re: [jose] Use of AES-HMAC algorithm - Consensus Request

[John Bradley <[e-mail]>]

I support the change.

On 2013-04-04, at 7:51 PM, "Jim Schaad" <[e-mail]> wrote:

> <chair> 
> 
> At the request of the editors, this is a formal consensus call on the first
> item in the list below.  If there are objects to use a single long key
> rather than a KDF function for the AES-CBC/HMAC algorithm please speak up
> now.  To date nobody has said that I was wrong to assume the consensus on
> that item.
> 
> Call ends in one week.
> 
> Jim
> 
> 
>> -----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
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose