Re: [COSE] Update to the COSE-HPKE draft and new use case (?)

[Hannes Tschofenig <[e-mail]>]

Hi all

I have created a PR to add the use case described below into the COSE-HPKE draft:
https://github.com/cose-wg/HPKE/pull/5

I briefly talked about this topic at the IETF meeting in Vienna. Comments welcome!

Ciao
Hannes

From: Hannes Tschofenig
Sent: Monday, February 28, 2022 4:05 PM
To: [e-mail]
Cc: Richard Barnes <[e-mail]>; Chris Wood <[e-mail]>
Subject: Update to the COSE-HPKE draft and new use case (?)

Hi all,

Following the virtual interim meeting we have updated the draft and here is a recent snapshot:
https://github.com/cose-wg/HPKE/blob/main/draft-ietf-cose-hpke.txt

Here are the slides from that meeting:
https://datatracker.ietf.org/meeting/interim-2022-cose-01/materials/slides-interim-2022-cose-01-sessa-cose-hpke-00

At that meeting we made progress on two open issues:


  1.  Simplify the layering (to a 2-layer model), as proposed by Ilari.
  2.  Not to introduce new parameters for HPKE algorithms but instead have the HPKE authors to add a note to their draft so that new value registrations are automatically populated into the IANA COSE registry.

There are additional open issues described in the slide deck that require further discussion in the group. I will add those to the Github open issue list.

A new aspect raised by Richard and Chris (on CC), in an off-list review, is to add an even more "optimized" layering. As a reminder, they currently described layering (see link to the draft snapshot) encrypts a CEK via HPKE and places the encrypted CEK in layer 1. Then, the plaintext in layer 0 is encrypted using that CEK. This design was selected for use with firmware encryption in mind (plaintext is the firmware image in this case). Richard believes that there are use cases where this intermediate step is not needed. Consequently, there would be only one layer and HPKE is thereby directly applied to the plaintext.

I would like to bring this issue to the list for discussion since adding such functionality to the draft requires changes. Below is an example for you to visualize the result of what Richard&Chris are asking for (if I correctly understood it):

96(
    [
        << {1: -100} >>, / algorithm id -100 for HPKE/P-256+HKDF-256 and AES-128-GCM /
        {
            / ephemeral public key structure /
            -1: << {
                1: 2,
                -1: 1,
                -2: h'985E2FDE3E67E1F7146AB305AA98FE89B1CFE545965B6CFB066C0BB19DE7E489',
                -3: h'4AC5E777A7C96CB5D70B8A40E2951562F20C21DB021AAD12E54A8DBE7EF9DF10'
                } >>,
             4: 'kid-2'
        },
        / encrypted plaintext /
        h'4123E7C3CD992723F0FA1CD3A903A58842B1161E02D8E7FD842C4DA3B984B9CF'
    ]
)

(Ignore details - the high-level details matter here)

Thoughts?

Ciao
Hannes & Russ

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.