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

> Seems more like efficiency / economy trade-off. You don’t really need
both. There’s no security reason for one or the other.

That's right. Thank you for clarifying what I wanted to say.

Daisuke

2024年3月4日(月) 3:42 lgl island-resort.com <lgl@island-resort.com>:

> 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 <lgl@island-resort.com>:
>
>>
>> On Feb 29, 2024, at 1:01 PM, Ilari Liusvaara <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
>> https://www.ietf.org/mailman/listinfo/cose
>>
>
>