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
[email protected]
https://www.ietf.org/mailman/listinfo/jose
