Hi Daisuke,

I just wanted to provide a bit of background for Laurence, who had skipped that 
discussion.
I am fine with having the algorithm combination currently defined.

Ciao
Hannes


From: COSE <[email protected]> On Behalf Of AJITOMI Daisuke
Sent: Sunday, December 11, 2022 12:59 PM
To: Laurence Lundblade <[email protected]>
Cc: Ilari Liusvaara <[email protected]>; [email protected]
Subject: Re: [COSE] HPKE versions


(BTW, I noticed that 
MLS<https://www.ietf.org/archive/id/draft-ietf-mls-protocol-16.html#name-mls-ciphersuites>,
 an HPKE-centric message encryption, defines ciphersuites for HPKE. It is near 
publication, so not just some early draft a fair number of people think 
ciphersuites for HPKE are a good idea.. For example it defines 
MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519. If you really want to reduce code 
and message size this is the way to go. There’s definitely few bytes on the 
wire and you are only decoding one integer (plus the enc) That saving is 
probably why most of the public key crypto in COSE is ID’d by ciphersuite).

I think MLS and COSE-HPKE are completely different. COSE-HPKE is a generic 
common layer that does not assume a specific use case.
I would prefer a design that keeps as much of HPKE's cipher suite agility as 
possible.

--
Daisuke


2022年12月11日(日) 1:48 Laurence Lundblade 
<[email protected]<mailto:[email protected]>>:
+1 for HPKE-v1-BASE

Re title the draft "HPKE Base Mode for COSE” or similar because it’s not a 
definition of all of HPKE for COSE

Use a fixed array for the sender info that is tied to HPKE-v1-BASE. If there 
becomes a need to change the array, then we’ll use.an algorithm identifier 
different from HPKE-v1-BASE. For example, we could have a different array for 
HPKE-v1-AUTH (if/when someone gets around to it and there is actual need for it 
to be different).

I’m pretty sure HPKE and COSE are well enough understood that we can fix the 
array now. A fixed array is definitely less code than a map or a variable 
array. For example with a map you have to do duplicate detection.

LL


(BTW, I noticed that 
MLS<https://www.ietf.org/archive/id/draft-ietf-mls-protocol-16.html#name-mls-ciphersuites>,
 an HPKE-centric message encryption, defines ciphersuites for HPKE. It is near 
publication, so not just some early draft a fair number of people think 
ciphersuites for HPKE are a good idea.. For example it defines 
MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519. If you really want to reduce code 
and message size this is the way to go. There’s definitely few bytes on the 
wire and you are only decoding one integer (plus the enc) That saving is 
probably why most of the public key crypto in COSE is ID’d by ciphersuite).




On Dec 9, 2022, at 6:16 AM, Ilari Liusvaara 
<[email protected]<mailto:[email protected]>> wrote:

On Fri, Dec 09, 2022 at 11:17:32AM +0000, Hannes Tschofenig wrote:

Hi all,

I would like to get some clarity from the version discussion.

At the beginning we discussed the following question: Do we need
something other than base mode for HPKE when used with COSE?

IMO, not currently. However, we should ensure, that such things can be
added in future without allocating new parameters. Which in turn impiles
that HSI (HPKE Sender Info) is either dictionary or polymorphic.
However, since each mode is its own special snowflake, I do not see need
for IANA registry.



Then, the discussions moved into how to encode future versions of HPKE
into the algorithm identifier. To me the discussion is a bit abstract
since there is (at least to my knowledge) to plan to work on a new
version of HPKE (given that the current version is not old).

Situation with future versions is even worse than with auth-MAC: With
auth-MAC, one at least knows what information needs to be encoded. But
with future versions, nobody even knows what is needed.

So beyond ensuring HSI parameter is extensible, there is nothing that
can be done.



So in summary:

- Do just HPKE-v1 base mode for now.
 - Possibly other stuff in future.
- Define HSI so that set of fields can change.
 - Parametrized by alg.
 - No need for registry.




-Ilari

_______________________________________________
COSE mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/cose

_______________________________________________
COSE mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/cose
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose

Reply via email to