Hi Laurence, Two-layer COSE-HPKE is structurally the same as -25. If we take out > COSE_KDF_Context and don’t provide an equivalent we are going backwards.
It's not correct. Two-layer COSE-HPKE is not similar to -25, but -29. To illustrate using HPKE, in direct key agreement (-25, etc.), KEM and KDF are done at layer1, and AEAD is done at layer0. On the other hand, in COSE-HPKE key encryption, KEM, KDF, and AEAD all are done at layer1 for CEK encryption. This is the same as Key Agreement with Key Wrap (-29, etc.). As you mentioned, next_alg is not a solution for -29. From my understanding, next_alg makes sense primarily for direct key agreement and is not related to COSE-HPKE. There are legitimate use cases for non-AEAD algorithms. For example, > firmware encryption is a legitimate use case for counter mode. That is > agreed upon my many people here. Understood. I thought it would be better if the encryption options available at layer0 could be limited to authenticated ones, but I see now that it is difficult. Anyway, in COSE-HPKE key encryption, the key encryption at layer1 is protected by HPKE and is not affected by the lamps attack. The discussion about the keys used at layer0 is independent of layer1, and in my opinion, does not need to be considered in COSE-HPKE draft, regardless of whether non-AEAD algs can be used at layer0. Daisuke 2024年3月20日(水) 3:59 lgl island-resort.com <[email protected]>: > > > On Mar 18, 2024, at 3:33 PM, AJITOMI Daisuke <[email protected]> wrote: > > > > > Even if the WG agrees to prohibit non-AEADs, I think we should get rid > of COSE_KDF_Context and should authenticate the algorithm ID across layers > with a new Enc_structure. > > > > I also think we should get rid of COSE_KDF_Context, but under the > premise of prohibiting the use of AE algs, I don't understand why it is > necessary to introduce next_alg... > > Because it is common security practice today to provide such protection. > > The COSE -25 algorithm is clearly and successfully protected against the > lamps attack by COSE_KDF_Context. Two-layer COSE-HPKE is structurally the > same as -25. If we take out COSE_KDF_Context and don’t provide an > equivalent we are going backwards. > > There are legitimate use cases for non-AEAD algorithms. For example, > firmware encryption is a legitimate use case for counter mode. That is > agreed upon my many people here. > > Even if an AEAD is used, there might be an attack that we haven’t thought > of. It’s good to have a prevention in anticipation of such. Clearly, the > design of COSE_KDF_Context anticipated an attack like the lamps attack. > > If this were complex or costly I’d be more empathetic, but it’s not. It’s > no additional bytes on the wire. It’s only a small amount of code. > > (yes this doesn’t immediately solve -29 with the key wrap in the middle; > I’m just focusing on COSE-HPKE) > > LL > > >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
