> > Unfortunately, currently no algorithm that takes a key (as opposed to > giving a key) can protect the algorithm at next layer.
I agree. The content_encryption_alg (next_alg) cannot be a countermeasure to the lamps attack on KAwKW(-29, etc.) and two-layer COSE-HPKE. Of course, it is effective against the attack on direct KeyAgreement (-25, etc.) and I think it's much better than COSE_KDF_Context. I believe what we should consider is only whether non-AEAD algs should be prohibited at layer0 or not. I think it would be better to be prohibited if possible. Daisuke 2024年3月22日(金) 19:55 Ilari Liusvaara <[email protected]>: > On Thu, Mar 21, 2024 at 06:54:16AM +1000, Orie Steele wrote: > > This is the main thing we need to address in COSE HPKE: > > > > > What matters is that the algorithm ID at layer 0 is protected. It must > > always be protected no matter what type of COSE or HPKE or CMS or JOSE we > > are considering. > > Unfortunately, currently no algorithm that takes a key (as opposed to > giving a key) can protect the algorithm at next layer. > > And then some such algorithms can not even be easily modifed to do so > (RSA-OAEP is the worst here, but even AES-KW is pretty bad). > > > CMS went with different solution due to having this exact same issue > with algorithm chaining and allowing unauthenticated encryption. > > JOSE takes care of this issue by strictly prohibiting unauthenticated > content encryption (RFC 7516, section 4.1.2.). > > > > >From a terminology perspective, I think "next alg" is not a great name, > and > > while I liked the generic depth construction from illari, it seems > overkill > > for HPKE, which only supply 2 layers. > > There can be more than 2 layers (pull-pull). > > That nobody has figured out any sensible use for that does not mean it > is not valid. > > (Maybe COSE BCP could recommend against using anything except the four > cases with known sensible use: direct, push, pull and pull-push). > > > > Let me try a refinement of the previous proposals: > > > > HPKE_AAD = CBOR([ > > "HPKE-Key-Encryption", content_encryption_algorithm, > > recipient_protected_header, > > external_aad > > ]) > > > > Yes, external AAD at this layer is strange, but it enables private > > information, which we lost when rejecting COSE KDF Context. > > That situation already arises if one composes Key Agreement with Key > Wrap from some Direct Key Agrement and some AEAD algorithm (pull-push). > > Perfectly valid and sensible thing to do, despite no known > implementation supporting it. > > > > > -Ilari > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
