On Mar 20, 2024, at 1:54 PM, Orie Steele <[email protected]> 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. In HPKE, the AAD enc structure is the best place to do it ( we discussed alternatives and dismissed them already ). Agreed. We need to protect the algorithm directly because in COSE protected headers are not required to carry algorithms. 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. Yes. “content_encryption_algorithm” seems pretty good. Along with explanatory text that says what it does. If this were applied to COSE -29 it would identify the layer 0 algorithm (e.g., AES-GCM) not the key wrap algorithm. I believe that solves the lamps attack for COSE -29. The key wrap algorithm is already identified securely as part of the COSE_Recipient algorithm ID. (Previously and in the COSE KDF Context implementation I thought of it as identifying the key wrap since that was “next"). The fixed COSE -29 would of course not have alg ID -29 since it would not be compatible with -29. We would author another RFC that that deprecates -29. RFC 9052 Appendix B has a three-layer example. There’s no need to use it because -29 exists (-29 is an optimization of this example), but this three-layer example would not be protected by the proposed structure below. That seems OK. 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. Yes, agreed that we must have this here. Maybe call it “recipient_aad” to be more clear? The depth is part of the context string, and in the case that recipient protected header has no algorithms, HPKE internally commits to the hole suite anyway. I think I prefer this be “Recipient_structure” as I think it is usable beyond HPKE. LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
