Re: [COSE] Wire-format ... was RE: Next steps with COSE-HPKE .... was RE: HPKE: Ephemeral public key encoding

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

I share Ajitomi-san’s opinion on COSE-HPKE.

 

--

V/R,

Uri

 

There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

                                                                                                                                     -  C. A. R. Hoare

 

 

From: COSE <[e-mail]> on behalf of AJITOMI Daisuke <[e-mail]>
Date: Thursday, September 15, 2022 at 14:33
To: Hannes Tschofenig <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [COSE] Wire-format ... was RE: Next steps with COSE-HPKE .... was RE: HPKE: Ephemeral public key encoding

 

Hi Hannes

 

Thanks for the response.

your design goal is to avoid changes to your COSE code when adding new HPKE algorithms.

 

Not only code but also the COSE-HPKE specification in itself but yes. It is one of my design goals.

 

1) There is no guarantee that enc can be mapped to COSE_Key in the future, so if a new HPKE cipher suite is specified, it cannot be used on COSE immediately. Whenever a new cipher suite is added to HPKE, it is necessary to develop a mapping specification for COSE_Key (including alg/crv value registration to IANA) and implement an additional enc->COSE_Key conversion process in existing many COSE libraries. 2) When a recipient offers multiple candidates for the HPKE cipher suite, a sender needs to tell the recipient what the sender has chosen, and while AEAD and KEM are fine, there seems to be a lack of a way to tell the recipient about KDF in the current draft.
3) There is no point in specifying kty (and crv) as required parameters. It is a waste of bytes.
4) crv is used to put in KEM algorithm information, but this is not in line with the original definition of crv. Isn't this an abuse of crv?
5) This spec needs to clearly define how COSE_Key parameters are to be handled, and implementations need to support this. (For example, what to put in key_ops, and whether to allow "deriveKey" and/or "deriveBits"? etc.)

 

I have previously listed five problems above, each of which corresponds to my design goals as follows. I think not only 1) but also 2) and 3) are important.

 

1) The addition of a new HPKE algorithm does not cause any changes to the specifications and existing implementations on the COSE side.

2) HPKE cipher suites can be negotiated dynamically and flexibly between a recipient and a sender.

3) The information sent from a sender to a recipient is necessary and sufficient.

4) No abuse of existing specification definitions.

5) Easy implementation (compact specification).

 

The drawback is the definition of a 'HPKE sender information' structure, which carries all the information HPKE exposes.

 

I don't think it is a drawback, but if defining a new structure is a drawback in itself, so be it.

I believe that it is essential for the sender to have a way to inform the selected KDF and AEAD to the receiver in HPKE. This is related to the design goal 2) above.

My main interest is to reach a decision as soon as possible so that we can make progress with the spec. I will ask the chairs to run a consensus call on the design goal.


Okay. Sorry for bothering you with my proposal.

 

Regards,

Daisuke

 

2022年9月16日(金) 0:01 Hannes Tschofenig <[e-mail]>:

Hi Daisuke

 

your design goal is to avoid changes to your COSE code when adding new HPKE algorithms. The drawback is the definition of a 'HPKE sender information' structure, which carries all the information HPKE exposes.

 

I understand that design goal.

 

It is up to the group to decide whether they share this goal. 

 

My main interest is to reach a decision as soon as possible so that we can make progress with the spec. I will ask the chairs to run a consensus call on the design goal.

 

Ciao

Hannes

 

From: AJITOMI Daisuke <[e-mail]> 
Sent: Saturday, September 3, 2022 7:11 PM
To: Hannes Tschofenig <[e-mail]>
Cc: Ilari Liusvaara <[e-mail]>; [e-mail]
Subject: Re: [COSE] Wire-format ... was RE: Next steps with COSE-HPKE .... was RE: HPKE: Ephemeral public key encoding

 

Hi Hannes,

 

 

 


> First, the HPKE RFC says that it does not specify a wire-format. In fact, Section 10 of RFC 9180 is very explicit about this fact by saying “This document does not specify a wire format encoding for HPKE messages.”

Yes, you are correct. There is not any wire format definition in the HPKE spec.
The wire format should be defined by a higher-level protocol, and indeed I know ECH, ODoH, and OHTTP define it.


However, the encapsulated key (sender's ephemeral public key) output by KEM is a byte string and it is evident in the definition of Nenc in the HPKE RFC as follows.

> Nenc: The length in bytes of an encoded encapsulated key produced by the algorithm


All HPKE implementations output enc as a sequence of bytes. How this is transmitted is left to the higher-level protocol, but it would normally be put directly into the wire format. Indeed, ECH, ODoH and OHTTP do just that.
I think the problem is that there is little necessity to convert enc as a byte string to COSE_Key structure. There are many disadvantages as I mentioned, but the reason to convert is just because there is already a field (ephemeral key) defined, right?
In my opinion, the ephemeral key (COSE_Key) is inadequate to represent HPKE sender information including enc, and in addition, there is no assurance that it can be converted to COSE_Key in the future.

I believe it is very important that when new HPKE cipher suites are defined in the future, this specification and existing COSE library implementations need not be changed. This is easily achievable as described in my proposal.

> I will read through your proposal.

Thanks for taking your time.

Regards,
Daisuke

 

 

2022年9月4日(日) 0:47 Hannes Tschofenig <[e-mail]>:

Hi Daisuke,

Let me give you a very quick response on one item. I will read through your proposal.

➢ One point of concern during the IETF 114 meeting was there were several erroneous comments that the fact that enc is an octet string is implementation-dependent.

We had discussed this earlier on the list and there are two data points:

First, the HPKE RFC says that it does not specify a wire-format. In fact, Section 10 of RFC 9180 is very explicit about this fact by saying “This document does not specify a wire format encoding for HPKE messages.”

Second, since Ilari did not believe me I reached out to Chris Wood, one of the authors, and ask him personally. He confirmed my observation.

The pseudo-programming language API defined in the HPKE RFC is not mandatory to implement by an HPKE library. In fact, there are implementations that do not implement that API and they are still compliant to the HPKE RFC. An example is the HappyKey implementation by Stephen Farrell. I used his implementation and used the PSA Crypto API rather than OpenSSL.

Ciao
Hannes
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
[e-mail]
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.