Re: [Teep] [Suit] ECDH-ES + A128KW vs. ECDH-ES + HKDF-256

[Hannes Tschofenig <[e-mail]>]

Hi Laurence,


I believe these are two different aspects but it is, of course, worth
checking it again.


The algorithm input to the KDF context structure is something Ken and I
coincidently discussed last week.


Initially, we used the algorithm id used for encrypting the firmware
image in the KDF context. Then, we changed it to the algorithm id used
in the recipient structure to encrypt the CEK, which is A128KW in our
example below. This reflected our reading of the COSE specification*.
When Ken explored the use of ECDH-ES + HKDF-256, it was not clear
anymore what algorithm id to include in the KDF context.


*: The relevant paragraph from Section 5.2 of RFC 9053 is when Jim
talked about the AlgorithmID and said:

"This field indicates the algorithm for which the key material will be
used. This normally is either a key wrap algorithm identifier or a
content encryption algorithm identifier."


Of course, this leaves room for interpretation because the keying
material derived by ESDH is used twice, first to encrypt the random CEK.
Then, the CEK is used to encrypt the firmware image. So, which usage of
the key is meant here?


Ciao

Hannes


Am 15.12.2023 um 04:14 schrieb lgl island-resort.com:
> Maybe I’m wrong here (hope so), but AES-GCM is used with ECDH-ES + A128KW for the bulk payload encryption and the algorithm ID identifying it is not mixed in with the KDF context so the alg ID is not really protected.
>
> Will look at the referenced paper some more.
>
> LL
>
>
>> On Dec 14, 2023, at 10:34 AM, Russ Housley <[e-mail]> wrote:
>>
>> Laurence:
>>
>> I am aware of a presentation about an attack against AES-GCM and AES-CCM:
>>
>> 	Roth, J. and F. Strenzke,
>> 	"AEAD-to-CBC Downgrade Attacks on CMS",
>> 	8 November 2023,
>> 	<https://datatracker.ietf.org/meeting/118/materials/slides-118-lamps-attack-against-aead-in-cms>.
>>
>> I am not aware of any attacks that involve AES-KW.
>>
>> Where can I find information about the attack you are talking about?
>>
>> Russ
>>
>>> On Dec 14, 2023, at 12:19 PM, lgl island-resort.com <[e-mail]> wrote:
>>>
>>> Note that there is a vulnerability in ECDH-ES + A128KW — the one that was presented in Prague. I think there are fixes, and it’s on my list to dig into it (IETF/COSE needs a full, proper and secure multi-recipient modern encryption format), but don’t have bandwidth right now.
>>>
>>> LL
>>>
>>>> On Dec 14, 2023, at 2:18 AM, hannes.tschofenig=[e-mail] wrote:
>>>>
>>>> Thank you all for your quick response. From the feedback it seems clear to go for ECDH-ES + A128KW
>>>> We will update the documents accordingly.
>>>>
>>>> -----Original Message-----
>>>> From: Suit <[e-mail]> On Behalf Of Akira Tsukamoto
>>>> Sent: Donnerstag, 14. Dezember 2023 06:29
>>>> To: Brendan Moran <[e-mail]>; Russ Housley <[e-mail]>; Hannes Tschofenig <[e-mail]>
>>>> Cc: [e-mail]; [e-mail]; Ken Takayama <[e-mail]>
>>>> Subject: Re: [Suit] [Teep] ECDH-ES + A128KW vs. ECDH-ES + HKDF-256
>>>>
>>>> Hi Brendan,
>>>>
>>>> I am fine changing the MTI with ECDH-ES + A128KW.
>>>>
>>>> Akira
>>>>
>>>> On 12/14/2023 12:08 AM, Russ Housley wrote:
>>>>> I think ECDH-ES + A128KW covers more use cases.  It can be used with on recipient or many recipients.  So, I'd like to see that be the MTI.
>>>>>
>>>>> Russ
>>>>>
>>>>>
>>>>>> On Dec 13, 2023, at 3:38 AM, hannes.tschofenig=[e-mail] wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> In the SUIT firmware encryption draft we have so far used ECDH-ES + A128KW, which is also what we implemented in t_cose to generate the examples.
>>>>>>
>>>>>> In a discussion with Ken today we realized that the SUIT-MTI draft has always used ECDH-ES + HKDF-256 instead.
>>>>>>
>>>>>> Now, the question is: Should we support both, ECDH-ES + A128KW and ECDH-ES + HKDF-256?
>>>>>>
>>>>>> IHMO we definitely need AES-KW for scenarios where we encrypt a firmware with a CEK once and then distribute that encrypted firmware image to many recipients. In this case, we
>>>>>>
>>>>>> * randomly generate a CEK,
>>>>>> * encrypt the firmware using this CEK,
>>>>>> * encrypt this CEK with a KEY unique per recipient with a KEK. The KEK is the result of using ECDH-ES with an KDF, as described in Section 6.4 of RFC 9053.
>>>>>>
>>>>>>
>>>>>> For scenarios where we send one firmware image to one recipient we could use ECDH-ES + HKDF-256 and currently we have a little bit of overhead here by using ECDH-ES + A128KW.
>>>>>>
>>>>>> My preference is to leave the SUIT firmware encryption draft as is and to change the SUIT MTI draft to reference ECDH-ES + A128KW instead of ECDH-ES + HKDF-256.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Ciao
>>>>>> Hannes
>>>>>>
>>>>> _______________________________________________
>>>>> TEEP mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/teep
>>>> _______________________________________________
>>>> Suit mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/suit
>>>>
>>>> _______________________________________________
>>>> Suit mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/suit
> _______________________________________________
> Suit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/suit