[COSE] Re: WGLC for draft-ietf-cose-hpke-13

[Laurence Lundblade <[e-mail]>]

> On Jun 21, 2025, at 11:07 AM, Ilari Liusvaara <[e-mail]> wrote:
> 
> On Sat, Jun 21, 2025 at 06:49:56AM +0900, AJITOMI Daisuke wrote:
>> Hi Hannes, Mike, all,
>> 
>> Over the past year, I haven’t been able to contribute to the revisions of
>> the specification despite being a co-author. However, I’ve reviewed the
>> latest content again and believe there are no major issues.
> 
> The COSE_MAC stuff seems very broken, at least in base mode. What is
> to prevent an attacker that has victim public key from choosing the
> message, MACing it with random key, and then encrypting the key to
> recipient?
> 
> That would not work in auth mode, but it is not supported (and it
> would still be a lot weaker than proper signatures).

I filed an issue so we don’t forget this: https://github.com/cose-wg/HPKE/issues/81


>> I’d feel a lot better about the “yes, let’s publish” if there was some
>>> comment and confirmation that next_layer_alg in Recipient_structure
>>> [3.1.2.1] secures the bulk encryption algorithm ID well enough that a
>>> non-AEAD can be used. I think it does, but we should have a little
>>> consensus on this.
>> 
>> At one point, I misunderstood your proposal, but I’m now confident that the
>> current approach is appropriate.
> 
> If an attacker changes the next layer algorithm from AE(AD) to non-AE,
> the aad will not match, which causes decryption failure with very high
> probability.

You’ve confirmed that next_layer_alg does the main job of defending against the lamps attack.

> Next_layer_alg does not help if the next layer algorithm is already
> non-AE, but that is a Bad Idea anyway.

Right. This is not to enforce against bad choices for the bulk content encryption. We can make recommendations, but that should be done elsewhere.

> Next_layer_alg also does not detect replacing bulk encryption with
> key wrap, but getting a valid key wrap seems very hard. Reusing other
> key wraps does not work, because that needs KEK, which would
> compromise the message anyway.

To clarify, if an attacker replaced AES-128-GCM with A128KW, next_layer_alg would cause it to be detected.

If a protocol designer created a three layer COSE encryption (e.g., HPKE-key-wrap-AES), next_layer_alg would secure the ID of the key wrap, but not the AES. This is more a problem with the three layer design than next_layer_alg, so no problem here either.

So, you’ve thought through the next_layer_alg design some and haven’t found a problem with it, right?. This makes me feel more confident. Thank you.

LL