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

[Mike Jones <[e-mail]>]

I'm in favor of the change.  I believe that this equivalent to issue http://trac.tools.ietf.org/wg/jose/trac/ticket/3 - correct?

				-- Mike

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Jim Schaad
Sent: Thursday, April 04, 2013 4:51 PM
To: [e-mail]
Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request

<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