Re: [CFRG] HPKE and Key Wrapping

[Dan Harkins <[e-mail]>]

   Hi,

   I'd like to resurrect this thread. There seemed to be some support for
adding an MRAE cipher to HPKE for key wrapping and also some support for
AES-SIV being the cipher to add do to its advantages over other key wrapping
schemes-- it accepts any length input without required padding out to some
particular block size, and it accepts associated data.

   At the last IETF I asked for a consensus call on 
draft-harkins-cfrg-dnhpke,
which proposes adding AES-SIV to the HKDF AEAD registry. If we advanced that
draft we'd have the permanent and readily available specification that is
required. Can we do that? Then all we'd need is the designated expert
to review and approve.

   I guess alternatively we could point to RFC 5297 as the permanent and
readily available specification. Then all we'd need is a designated expert.
Still, I'd like to see if there's support to advance my draft.

   regards,

   Dan.

On 3/31/22 4:50 AM, Neil Madden wrote:
>
>> On 31 Mar 2022, at 11:34, Ilari Liusvaara <[e-mail]> 
>> wrote:
>>
>> On Wed, Mar 30, 2022 at 04:15:44PM -0400, Russ Housley wrote:
>>> Martin:
>>>>
>>>> On Tue, Mar 29, 2022, at 20:05, John Mattsson wrote:
>>>>> Would it make sense to standardize AES-KWP for HPKE or do CFRG believe
>>>>> that AES-SIV is the future of key wrapping? Irrespectively I think the
>>>>> CFRF should produce a good recommendation on how to use HPKE for key
>>>>> wrapping.
>>>>
>>>> What is wrong with the existing HPKE cipher suites for protecting
>>>> keying materials?  That is, aside from not carrying a NIST
>>>> approval stamp.
>>>
>>> If you try to apply HPKE to the COSE or JOSE structures, it just does
>>> not quite fit.  However, by using HPKE to deliver a key-encryption key
>>> (KEK) to the recipient, the structures fit.  So, it would be really
>>> nice to use a Key-Wrap algorithm in HPKE to encrypt the KEK.
>>
>> Not sure about JOSE, but in COSE, the structures do fit even for direct
>> encryption. COSE-HPKE does not use receipients itself, so it can go into
>> cose_encrypt0, resulting in direct encryption.
>
> I’m not sure if this point is directly related to what is being 
> proposed here, but I think it is worth mentioning:
>
> JOSE and COSE allow sending the same message to multiple recipients 
> using key-wrapping. In the case of an authenticated KEM (AKEM), this 
> usage undermines the authenticity guarantees due to the lack of 
> Insider-Auth security (as per section 5.4 of 
> https://eprint.iacr.org/2020/1499.pdf) in HPKE AKEM. In short, any 
> recipient of the original message can simply take the unwrapped 
> content encryption key and use it to produce a new message that 
> appears to come from the original sender.
>
> This is why 
> https://datatracker.ietf.org/doc/html/draft-madden-jose-ecdh-1pu-04 requires 
> a compactly-committing AEAD for symmetric content encryption (DEM) and 
> includes the AEAD tag in the KEM KDF computation to ensure the KEM 
> encapsulation for each recipient is bound to the whole message. This 
> current design was arrived at after previous discussion on the CFRG 
> list 
> (https://mailarchive.ietf.org/arch/msg/cfrg/iNoSj9g2cQ0JvDbHs4I70bfhrRc/) 
> and some offline discussions.
>
> (An alternative approach is to include the AEAD tag in associated data 
> of the key-wrapping process, which is another advantage of SIV-AES 
> over AES-KW - the latter not supporting associated data).
>
> Kind regards,
>
> Neil
>
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius