Re: [jose] [COSE] HPKE PartyU / PartyV

[Orie Steele <[e-mail]>]

I think we actually agree here.

The remaining point is just what to do in HPKE.

1. New header parameters, mandatory processing rules, mix
content encryption algorithm into the KDF (via HPKE INFO).
2. New Enc_structure, (fix disconnected layers vulnerability), protect
"Enc_structure" with AAD (via HPKE AAD).

What JWE allows, is based on the algorithms it relies on, and their
processing rules are algorithm specific, for example:

https://datatracker.ietf.org/doc/html/rfc7518#section-4.6.1.2

So both 1 and 2 can also work for JOSE, except that there is no
"Enc_structure", there is just the normative language regarding:

"What to set for HPKE AAD in seal and open" and "What to set for HPKE
INFO"...

If we are not going to create COSE_KDF_CONTEXT, then suggest we will also
not create ConcatKDF context in JOSE.

So HPKE INFO, will be the same in both JOSE HPKE and COSE HPKE.

The guidance that JOSE provides regarding using the protected header bytes
as aad, seems reasonable.

https://datatracker.ietf.org/doc/html/rfc7516#appendix-A.4.5

"""
Let the Additional Authenticated Data encryption parameter be
ASCII(BASE64URL(UTF8(JWE Protected Header)))
"""

When you apply this guidance to HPKE Direct / Integrated Encryption, there
is only the top level protected header to consider since there is only a
single recipient.

When you apply this guidance to HPKE Key Encryption, in JOSE, you are
"mixing layers", but that's ok to do, because there is no way to understand
any of the HPKE algorithms in the context of JOSE without reading the RFC
that defines that behavior... which we are hopefully progressing through
these debates : )

The logic for COSE is the same, regarding proposals 1 and 2.

I like your comment regarding the fully specified algorithms draft...
considering the encryption use case for fully specified algorithms:

https://www.rfc-editor.org/rfc/rfc7520#section-5.6.3

{
     "alg": "dir",
     "kid": "77c7e2b8-6e13-45cf-8672-617b5b45243a",
     "enc": "A128GCM"
}

{
     "alg": "dir",
     "kid": "77c7e2b8-6e13-45cf-8672-617b5b45243a",
     "enc": "HPKE-Base-P256-SHA256-AES128GCM"
}

I would consider both of these cases "fully specified".

One is fully specified by listing a single AEAD algorithm.

The other is fully specified by listing an HPKE SUITE, that bundles KEM,
KDF and AEAD together.

In the context of COSE, we don't have "enc", but we do have fully specified
algorithms for COSE HPKE.

Thanks for your comments.

Regards,

OS




On Thu, Feb 29, 2024 at 8:48 AM Ilari Liusvaara <[e-mail]>
wrote:

> On Wed, Feb 28, 2024 at 03:31:26PM -0600, Orie Steele wrote:
> > >
> > >
> > > <snip>
> > >
> >
> >
> > > JWE requirements imply that if { alg: dir, enc: HPKE...A128GCM } is
> > > legal, then { alg:ECDH-ES, enc: HPKE...A128GCM } is also legal. But
> > > the latter tries to derive HPKE key from Direct Key Agreement, which is
> > > absurd. Contradiction. Therefore { alg: dir, enc: HPKE...A128GCM } can
> > > not be legal. Q.E.D.
> > >
> >
> > JOSE HPKE can say:
> >
> > When using direct encryption, set the protected header "alg" to "dir",
> set
> > the "enc" value to "HPKE...A128GCM".
> > Values other than "dir" MUST NOT be used when "enc: HPKE...A128GCM" is
> > present in protected headers.
> > Direct encryption with HPKE MUST NOT be used with more than one
> recipient.
>
> No, JWE does not allow doing that.
>
>
> > That being said, we could add new values for integrated encryption, and
> the
> > same argument would apply:
> >
> >  { alg: hpke-ik, enc: HPKE...A128GCM } or { alg: HPKE...A128GCM, enc:
> > hpke-ik }
> >  { alg: hpke-ik, enc: A128GCM } or { alg: ECDH-ES, enc:  hpke-ik }
>
> I don't think that would be a good idea.
>
> And it would also violate section 5 of
> draft-ietf-jose-fully-specified-algorithms-01.
>
> If adding a new sort of thing, it should be added into space that was
> previously invalid. One such is missing "enc".
>
>
> > Arguing a contradiction from a false (absurd) premis, is invalid.
>
> If x => y and y is false, then x is false.
>
>
> > > > * COSE: HPKE AAD is CDE of Enc_Structure, just like for symmetric
> AEAD.
> > > >
> > > > ^ I do not understand how this proposal secures both the recipient
> > > > protected header, and the top level protected header, while
> addressing
> > > the
> > > > oracle attack.
> > >
> > > It does not. Because the only way to address oracle attack without
> > > breaking changes are via totally different kind of mechanism.
> > >
> >
> > LAMPs draft addresses it by mixing the content encryption AlgorithmID
> used
> > into the KDF.
> >
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-cek-hkdf-sha256-00#section-5.1
>
> Because that is the only way to fix it in CMS without breaking change.
>
>
> > That's a layer violation in traditional COSE, but because there is no
> > COSE-HPKE,
> > that can be the default behavior if we write text that makes it so.
>
> That is still a breaking change (breaks any library interface assuming
> no layer-mixing)
>
>
> > This is why I pointed at COSE_KDF_CONTEXT... we could try solving this
> > problem using it.
> > but since it's mostly redundant to HPKE, that seems like a bad idea.
>
> Yeah, using COSE_KDF_Context with HPKE is a bad idea.
>
>
> > That leaves only HPKE INFO and HPKE AAD as the possible places to address
> > this.
>
> That assumes it is addressed. However, there is no way to do so without
> a breaking change (see above).
>
>
> > I'd be happy to review your alternative proposals.
>
> A hacky HPKE-specific fix would be to require that keys encrypted by
> HPKE MUST NOT be used for unauthenticated encryption without KDF step
> in between.
>
>
> The proper way to fix it is to add a header parameter that adds a KDF
> step between the CEK and the actual key used in symmetric encryption.
>
> And then add a requirement that any key used for unauthenticated
> encryption MUST come from KDF.
>
>
> > > > Since HPKE is new, we don't have to forward the vulnerable 2 layer
> > > behavior
> > > > for the case where all algorithms in a 2 layer are HPKE algs.
> > > >
> > > > We cannot fix the oracle attack in a "mixed alg" 2 layer cose
> structure,
> > > > because it would require breaking changes.
> > >
> > > Just fixing it for HPKE would already require breaking changes (by
> > > introducing layer-mixing)
> > >
> >
> > This is false, because there is no JOSE or COSE HPKE.
> >
> > By default, any new HPKE algorithm will be new functionality for
> libraries,
> > and can therefore not be called a breaking change... since there is
> nothing
> > to break.
>
> It breaks any library interface that assumes no layer-mixing. Which is
> a reasonable assumption, given that currently everything layers neatly.
>
>
>
>
> -Ilari
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>