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

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

<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