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 <[email protected]> on behalf of AJITOMI Daisuke
<[email protected]>
Date: Thursday, September 15, 2022 at 14:33
To: Hannes Tschofenig <[email protected]>, "[email protected]"
<[email protected]>
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 <[email protected]>:
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 <[email protected]>
Sent: Saturday, September 3, 2022 7:11 PM
To: Hannes Tschofenig <[email protected]>
Cc: Ilari Liusvaara <[email protected]>; [email protected]
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 <[email protected]>:
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
[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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
