>
>
> <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.
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 }
Arguing a contradiction from a false (absurd) premis, is invalid.
>
> > * 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
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.
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.
That leaves only HPKE INFO and HPKE AAD as the possible places to address
this.
Overload an existing Enc_Structure (since none has ever been used for HPKE,
this can be done in HPKE draft text).
Or define a new Enc_Structure.
Or set top layer protected header as HPKE info, and Enc_Structure as
HPKE AAD.
I'd be happy to review your alternative proposals.
>
>
> > 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 will be a breaking change to come back and fix it later, after
publishing COSE HPKE with the same layer vulnerability.
>
>
>
>
> -Ilari
>
> _______________________________________________
> COSE mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/cose
>
--
ORIE STEELE
Chief Technology Officer
www.transmute.industries
<https://transmute.industries>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
