On Tue, Jul 18, 2023 at 05:33:09PM +0000, Michael Jones wrote: > 14:25-14:40 Summary of contentious issues in HPKE (15 minutes) - Orie > Steele
Skipping the first question (because it is more complicated), here are my thoughts on the rest: - Should “enc” be opaque in COSE / JOSE? I think yes, for the following reasons: * "enc" enters cryptographic calculations. This guarantees interoperability with raw bstr form. And any transformation done by sender has to be undone by the receiver. * "enc" for arbitrary KEM can not be encoded as COSE_Key / JWK. There already exists usable KEM where this fails. * Even future DHKEMs can fail to be encodeable as COSE_Key / JWK. * Switching between two header parameters depending on if the enc can be encoed as COSE_Key / JWK or not increases complexity a lot. * Compressed keys would save space, but the CP-x stuff from draft-harkins-cfrg-dnhpke-02draft-harkins-cfrg-dnhpke-02 is smaller still with no drawbacks. There was some confusion as to to status of KEM48 (X25519+Kyber). Best to treat it like it was from published Experimental RFC. It is certainly intended to be fully interoperable and stable. - Should COSE HPKE specification support all modes? There is a big pitfall here... Auth(PSK) modes can only safely be used with one-layer structure. There is an attack if those are used in two-layer structure. - What information should be included in the key derivation function? I think, by default, either empty or some fixed string, for the following reasons: * COSE already allows applications to modify COSE_KDF_Context in non- interoperable ways. * The parameters to bind all seem to be either application-specific or bound in other ways. A while back, I thought some ideas about what applications might want do here, and COSE_KDF_Context did very badly. * One reason for fixed string would to not have collisions with other protocols, even if operations would fail either way. - Should the confidentiality and integrity be treated independently? I am bit confused what this means. Some candidates: - Unauthenticated encryption: This is not supported by HPKE. - HPKE Auth(PSK) mode: Only works in single-layer structure. - COSE_MAC: Here be dragons. The Github issue also talks about stream authentication. The limitations of HPKE Auth make it unsuited for the purpose. Not that COSE is suitable for describing streams. - Should it also be specified for COSE_MAC? I think no. Analyzing constructs like this is above my paygrade, but I do know it could very easily go very wrong. The security considerations for such thing would likely be something very funky. - Should the specification be API agnostic? I think mu. The API of HPKE defines the allowed operations. Any interface description of HPKE would still have the SealBase() and OpenBase() functions. Hopefully with much less corner-cutting than in RFC9180. - Externally Supplied AAD only processed at layer 0? I think yes, because such externally suppiled AAD is associated with the message, not with the key wrapping. Presumably external aad associated with key wrapping (if some application needs that for some reason) would be suppiled sepatedly for that purpose. And it is already possible to already hit this issue even in RFC9052/ 9053, as nothing prohibits using AES-GCM or Chacha20-Poly1305 in both layers 0 and 1 (even if nothing supports that). Then one has two external aad fields. - Should there be one-layer mode? I think yes, because one-layer and two-layer modes are natural consequence of having one layer thick AEAD in COSE (not true in JOSE!). -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
