Because of how COSE handles bulk encryption, any new algorithm that
encrypts a content encryption key needs to explain how that key is
protected from cross mode attacks.

The modes are distinguished by what goes into the HPKE AAD or info, and
their cbor tags.

I think the current proposal is to put protected headers in normal enc
structure and set that as AAD for "integrated encryption"

and to put header parameters in a new hpke specific enc structure and set
that as AAD for "key encryption" (protecting against cross mode).

There are other changes we need to make, like removing HPKE modes from the
algorithm, adding support for auth / psk / pks_auth, etc...

JOSE has the exact same issues, but does not have the concept of "enc
structures"... currently HPKE AAD in JOSE is computed as the text
concatenation of protected headers, "." and jwe aad.

In COSE the proposal seems to have been to pull the content encryption
algorithm parameter out of the header, or simply add it to the hpke enc
structure, since "alg" is optional in COSE, you cannot protect against
cross mode, by assuming the header contains an algorithm and using the
header alone as aad.

I'm happy to implement any protection against the cross mode attack that
the working group can agree too.

Laurence's proposal for HPKE specific enc structure seems the most viable
to me.

Regards,

OS



On Mon, Jul 8, 2024 at 9:47 AM Ilari Liusvaara <[email protected]>
wrote:

> On Mon, Jul 08, 2024 at 04:51:23AM -0700, [email protected] wrote:
> > Internet-Draft draft-ietf-cose-hpke-08.txt is now available. It is a
> work item
> > of the CBOR Object Signing and Encryption (COSE) WG of the IETF.
> >
> >    Title:   Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object
> Signing and Encryption (COSE)
> >    Authors: Hannes Tschofenig
> >             Orie Steele
> >             Daisuke Ajitomi
> >             Laurence Lundblade
> >    Name:    draft-ietf-cose-hpke-08.txt
> >    Pages:   22
> >    Dates:   2024-07-08
>
> The discussion of modes has some issues:
>
> - RFC9052 defines "Direct Encryption" mode, with conflicting meaning.
> - There is no need to have two modes:
>
>   Bulk encryption algorithms work on layer 0 (by definition). And by
>   RFC9052 section 5.3, placing bulk encryption algorithm as recipient of
>   an AEAD algorithm will cause it to encrypt the CEK instead of message.
>
>
>
>
> -Ilari
>
> _______________________________________________
> COSE mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to