Re: [jose] [COSE] HPKE PartyU / PartyV

That’s helpful.

If you read the paragraph before you get more context and more understanding why there’s both. Seems more like efficiency / economy trade-off. You don’t really need both. There’s no security reason for one or the other.

Using aad like Ilari said, seems good to me.

LL

On Mar 3, 2024, at 1:33 AM, AJITOMI Daisuke <ajitomi@gmail.com> wrote:

I haven't been able to read through all of the long discussions so far, but ...

Ilari, even if you can’t say why, can you tell us where the text that prohibits use of both INFO and AAD is?

I think this is about the following in Section 8.1 of RFC9180:

Applications that only use the single-shot APIs described in Section 6 should use the Setup info parameter for specifying auxiliary authenticated information. Implementations which only expose single-shot APIs should not allow applications to use both Setup info and Context aad or exporter_context auxiliary information parameters.

It's not prohibited, but it says "should not''.

This essentially means that, in HPKE, In HPKE, both INFO and AAD serve the same role of binding information from the application layer to the HPKE process and the difference between INFO and AAD only comes down to whether the same can be used across multiple EncryptionContexts (INFO) or not (AAD).

I believe that at least the authors of HPKE regard both in this way.

Best,
Daisuke

2024年3月2日(土) 4:23 lgl island-resort.com<http://island-resort.com/> <lgl@island-resort.com<mailto:lgl@island-resort.com>>:

On Feb 29, 2024, at 1:01 PM, Ilari Liusvaara <ilariliusvaara@welho.com<mailto:ilariliusvaara@welho.com>> wrote:

On Thu, Feb 29, 2024 at 11:04:57AM -0600, Orie Steele wrote:
I think we actually agree here.

The remaining point is just what to do in HPKE.

1. New header parameters, mandatory processing rules, mix
content encryption algorithm into the KDF (via HPKE INFO).

HPKE does not allow using both INFO and AAD for one message (I do not
know why), and INFO has a short length limit (because it is used in
ways that pretty much require buffering).

So only AAD can be used.

Illari, even if you can’t say why, can you tell us where the text that prohibits use of both INFO and AAD is?

Note that COSE -25 and -29 allow the input of a salt into the KDF outside of COSE_KDF_Context. If we wanted to do similar in COSE-HPKE, use of the info parameter is the obvious place.

I can’t see any technical reason that both couldn’t be used and I wonder if there is some reason we might want to allow COSE-HPKE users to be able to supply inputs to the KDF function.

Or asked another way, what are the security trade-offs between AAD and INFO? There’s lots of security considerations in RFC 9180, but none seem to discuss this.

I don’t see an issue here, but it would be nice to understand.

Thx!

(RFC 9180 is impossible to search because the variable names used in the Python code are so short. “info” occurs almost 200 times)

LL
_______________________________________________
COSE mailing list
COSE@ietf.org<mailto:COSE@ietf.org>
https://www.ietf.org/mailman/listinfo/cose