Re: [CFRG] HPKE and Key Wrapping

[Neil Madden <[e-mail]>]

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