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

["lgl island-resort.com" <[e-mail]>]

I think both algorithm IDs should be protected. Both the AES-KW and the AES-GCM identifier.

The main reason is to provide very thorough protection. Protecting both algorithm IDs may prevent attacks we don’t even know about today. This is the level of security and quality that IETF/COSE should work too.

Seems like HPKE used this kind of thinking (but didn’t support multiple recipients).

I haven’t thought it through completely, but I think HPKE is probably not vulnerable to the AEAD downgrade attack described in Prague, because it used that kind of approach.

I don’t think the COSE work did for ECDH plus KDF is as thorough as HPKE’s work, but CMS is worse than COSE.

It’s not a matter of trying to figure out what 9053 intended. It’s a matter that it didn’t go as far as it should.

Seems like there’s many different approaches to fixing this ranging from trying for as little work as possible like having all the alg IDs in the KDF input to something very major like adding multiple recipient support to HPKE.

This is an incomplete message as I am not proposing anything and that I’m not providing analysis to properly link up to the AEAD downgrade attack. This stuff is hard for me to think about...

LL


 
Also, the COSE documents are sort of incomplete, in that they leaves some very difficult security analysis for the implementor in the area of KDF input  in contrast that to the extensive warnings about AES-CTR mode in RFC 9459 that expect the reader knows very little. Personally, I learned about AES-CTR mode issues twenty-thirty years ago and think it is common knowledge.


> On Dec 17, 2023, at 8:20 AM, Hannes Tschofenig <[e-mail]> wrote:
> 
> 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