Hi Laurence, First of all, I appreciate your efforts to separate your personal preferences and base the discussion on objective facts.
*Compatibility with COSE* COSE today centers around a single integer algorithm ID. This is the only > type of algorithm ID defined in 9052 and 9053. It is used in all the > message types and for COSE_key. This is not true. As John Mattsson (and maybe Ilari) also pointed out, in COSE/JOSE, a specific cryptographic algorithm is not determined by the algorithm ID alone, but in combination with the key parameters. So it should be stated as "COSE today centers around *a combination of key parameters and* a single integer algorithm ID* bound to the key operation*." Please see the following examples: - kty: OKP + crv: Ed25519 + alg: EdDSA - kty: EC + crv: P-256 + alg: ES256 (ECDSA-SHA256) - kty: EC + crv: P-256 + alg: ECDH-ES Does "EdDSA" alone specifically determine the cryptographic algorithm at the granularity of the HPKE cipher suite (a combination of kem/kdf/aead)? "HPKE-v1-Base" (perhaps it would be better to append "-KEM") could be considered closer to the above precedents (EdDSA, ES256, ECDH-ES) than Orie's proposal, at least in the sense that it doesn't express the details of the key. Moreover, all alg values are defined within the scope of the operation where the key is directly used (cryptographic agility per key operation). Orie's proposal significantly deviates from this convention. I believe it's clearly against the COSE convention to include AEAD information, which is originally unrelated to the key, in the alg value. What are your thoughts? Can you confidently say that deviating from the principle of "cryptographic agility per key operation" won't impact existing implementations or systems? It might be permissible to include up to KDF based on convention, as it falls within the scope of the derive_key operation, but including AEAD is clearly a deviation from COSE convention. Following the structure of HPKE, I believe it is accurate and better to keep the alg within the scope of KEM in COSE-HPKE. Any algorithm negotiation scheme built as suggested in 9052 section 10 is > going to support a single integer because most of COSE uses it. Therefore, this is also not true. As I mentioned above, the negotiation/determination of cryptographic algorithms at the same granularity as the HPKE ciphersuites is done by using not only alg but also the key parameters together. As an internal software process in COSE, alg is first used as a switch to invoke a module per algorithm category (EdDSA, ECDSA, ECDH), and the selection on a specific cryptographic algorithm is made primarily by the key parameters (including the key itself). Of course, alg is also used in the module, but mainly for deciding an additional hashing algorithm, etc. In addition, I couldn't find such a description you pointed out in RFC9052, section 10... Are you referring to the following part? I cannot interpret it the way you do. * Applications may need to provide some type of negotiation or discovery > method if multiple algorithms or message structures are permitted. The > method can range from something as simple as requiring preconfiguration of > the set of algorithms to providing a discovery method built into the > protocol. S/MIME provided a number of different ways to approach the > problem that applications could follow: As COSE is used more widely, other protocols and facilities will need to > identify algorithms. For example, X.509-like certificates. We won’t just > see algorithm identification in the COSE RFCs. Sorry. I did not understand this part. Could you please explain it in a bit more detail? > *Ease of Coding*Is it easier to pass an integer around or a structure? > What about error conditions and code size? This "ease of coding" is vague, and it tends to become a subjective measure and doesn't contribute to a productive discussion, in my opinion. This point should be narrowed down to whether there is a need to continuously maintain the implementation of the COSE layer. It is an essential and straightforward criterion. In that regard, the existing draft doesn't require maintenance, while Orie's proposal would require ongoing maintenance. With every addition of a new alg value, mapping rules would need to be implemented, the invocation conditions for the COSE-HPKE extension would need to be modified, tests would need to be added, and releases would be necessary. It is evident that the existing draft is superior. Furthermore, regarding COSE-HPKE, I believe it is necessary to consider the separation of the COSE layer and the HPKE layer. It is desirable from a software design perspective for the COSE layer to only have a pass-through mechanism to HPKE and delegate all matters related to HPKE to the HPKE layer. *Facilitating Algorithm Choice* > What I bring up here is how implementors and deployers will choose what > algorithm(s) to use. How will the pick from the lists of available > algorithms? > With a single integer we’ll only define a subset of all the combo’s of > what’s possible. We can make the decision easier for many by providing > fewer choices (and if someone doesn’t like the combo we’ve defined, they > have to either go to the trouble to define a new one or use one in the > proprietary space). I contemplated this issue using the example of MLS, which adopts the same approach as Orie's proposal. (Note that it's not a popular approach! All of the other HPKE application specs adopt the same approach as the current COSE-HPKE draft.) I would be glad if you could answer as a reply to "6. Ease of cipher suite selection by application" in my earlier post in this thread if it really facilitates the decision of the cryptographic algorithm. >From my point of view, the benefits obtained as a trade-off for sacrificing the significant advantage of flexibility are very small or perhaps non-existent. Even apart from the fact that it goes against the conventions of COSE, the design of forcefully squeezing HPKE into the alg field, resembling a ciphersuite, not only fails to make the selection easier but may even have the opposite effect. I think that making the decision to narrow down the alg values to just one (or two) might work. However, in the context of the COSE-HPKE specification, which should be generic, I consider it a clear mistake to do so. *Ease of adding a new HPKE KEM (or other alg)* ... > There will still need to be a major SW update for anyone to know about the > new KEM. ... > but probably the SW update that needs to be done no matter what sort of ID > we use is a much bigger task. As I mentioned above, we need to separate the COSE layer from the HPKE layer. The HPKE layer is most likely to be provided by a near-platform layer such as openssl. For example, iOS 17 recently added support for HPKE. https://developer.apple.com/documentation/cryptokit/hpke I think it is more in line with reality to assume that most COSE libraries will use HPKE functionality supplied as a dependent library/dependent platform. And keeping up with dependent library updates and dependent platform updates is an essential part of maintaining all software. To compare, once this common update work is put aside, we should focus only on the COSE layer. Looking only at the COSE layer, the costs associated with adding a new KEM are as follows. Note that none of these are necessary in the current COSE-HPKE draft at all. - Development of an RFC spec defining the algorithm IDs for the new KEMs, and registration with the IANA Registry - Is it really that easy to carefully select which ciphersuites to use with the newly added KEMs? I don't think it is that easy a task as it requires accountability for the rationale for the selection. - Even if you consider it easy, this is not just a document, it is an international standard. It will take more than 6 months to go through numerous expert reviews and become an RFC. - Updating the COSE layer implementation and documentation So are the additional costs above insignificant compared to keeping up with updates to dependent libs/platforms? Fortunately, with the proliferation of solutions such as github actions(dependabot, etc.) that make CI/CD effortless, this type of work has become much easier these days. (On average, I handle updates to dependent libraries as PRs from dependabot about once a day. I just open the github app on my phone and click the button a couple of times.) Thus, it's not a big task to begin with, and obviously a minor cost compared to the additional costs mentioned above (RFC publishing and updating the implementation and documentation). This is not a level of difference that depends on how you think about it, but rather, objectively speaking, there is a stark and significant difference. In summary, you did not directly respond to the 6 advantages of the existing draft that I listed in my earlier email in this thread, although you did present his factually based thoughts on my points of (1), (3), (4), and (6), As stated above, I must say that there are factual errors and a significant bias in the scoping and evaluation of the comparables. In addition to your responses to my points of (2) and (5), I would like to see you provide objective factual reasons why Orie's proposal should be taken. I do not see any advantage at all other than a reduction in message size by about a few bytes in COSE. Moreover, this advantage backfires in JOSE/JWK. Finally, The iOS 17 HPKE library cited above does not adopt a ciphersuite approach, but an a-la-carte approach. Why doesn't Apple, which also values the developer experience, adopt the ciphersuite approach? In my opinion, the generality required for the iOS HPKE library, which is limited to "apps that only run on iOS devices," is less than that required for COSE. I mean that there is a rationale for narrowing down the number of ciphersuites more than COSE-HPKE. I think this is related to what I wrote in an earlier email in this thread (6. Ease of cipher suite selection by application) and the following opinion I appended at the end. Finally, about the article that Orie seems to be influenced by: > https://www.blockchaincommons.com/musings/musings-agility/ > This article cites TLS1.3 as a good example of a modern approach that > limits cipher suites. > This characteristic of TLS1.3 applies to HPKE as well. > The KEM/KDF/AEAD algorithms of HPKE are already carefully selected. (The > variety of cipher algorithm options in TLS1.3 is even greater than that in > HPKE) > There should be no problem with showing the raw choices of each step in > HPKE to the higher levels. and, I think he prefers ciphersuites over cryptographic agility, but then how > many cipher suites should we define in the COSE-HPKE spec? > As a precedent, let's bring up the cipher suites carefully selected by > experts for MLS. > > https://www.ietf.org/archive/id/draft-ietf-mls-protocol-20.html#section-17.1 > I tried to express them in JWK/JOSE 'alg' values, but just enumerating > them is exhausting due to the length of these names. It's likely to lead to > typing mistakes or incorrect autocomplete, resulting in poor usability. > - "HPKEv1-Base-DHKEM(X25519,HKDFSHA256)-HKDFSHA256-AES128GCM" > - "HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA256-AES128GCM" > - "HPKEv1-Base-DHKEM(P25519,HKDFSHA256)-HKDFSHA256-ChaCha20Poly1305" > - "HPKEv1-Base-DHKEM(X448,HKDFSHA512)-HKDFSHA512-AES256GCM" > - "HPKEv1-Base-DHKEM(P521,HKDFSHA512)-HKDFSHA512-AES256GCM" > - "HPKEv1-Base-DHKEM(X448,HKDFSHA512)-HKDFSHA512-ChaCha20Poly1305" > - "HPKEv1-Base-DHKEM(P384,HKDFSHA384)-HKDFSHA384-AES256GCM" > Let me point out in advance that adding post-quantum KEMs or KEMs for > compressed or compact points for NIST curves will further increase the > variation, and there's no rational reason why COSE should limit this list > to fewer numbers. > Now, how much difference is there in the knowledge required for an > application designer to choose one out of these seven options, compared to > choosing one each from 5 KEMs, 3 KDFs, and 3 AEADs? > As you can see from the list of values defined as JOSE 'alg' values above, > the names are long and the similarities between each choice are high. > To choose the desired one from this list, you need to understand HPKE to > some extent. Ultimately, isn't this task almost the same as choosing one > each from 5 KEMs, 3 KDFs, and 3 AEADs? > Should we choose this policy, ignoring the demerits of No.1-5 above? > Moreover, the visibility of the JWK 'alg' value is low, and it is not > developer-friendly. > Next, let's imagine a situation where an application developer has to > specify a cipher suite. Is there a difference between the two examples > below? > AwesomeHPKEApp.new(suite={kem: DHKEM_X25519_HKDFSHA256(0x20), kdf: > HKDF_SHA256(0x01), aead: AES128GCM(0x01)}) AwesomeHPKEApp.new(suite="HPKEv1-Base-DHKEM(X25519,HKDFSHA256)-HKDFSHA256-AES128GCM") > > The former still has to internally decompose the suite_id into kem_id, > kdf_id, and aead_id. Best, Daisuke 2023年6月10日(土) 2:09 lgl island-resort.com <[email protected]>: > This is an attempt to structure this as an engineering trade-off decision > between pros and cons. I’m setting this up as a choice between 1) a single > integer alg ID like most of COSE today and 2) a data structure holding a > triple like we have in the latest COSE-HPKE draft. > > I’m trying to structure here with the facts and trade-offs separate from > my personal opinion. Hoping that we can agree on some of the facts, even if > we don’t have the same opinion. > > *Compatibility with COSE* > COSE today centers around a single integer algorithm ID. This is the only > type of algorithm ID defined in 9052 and 9053. It is used in all the > message types and for COSE_key. > > Any algorithm negotiation scheme built as suggested in 9052 section 10 is > going to support a single integer because most of COSE uses it. > > As COSE is used more widely, other protocols and facilities will need to > identify algorithms. For example, X.509-like certificates. We won’t just > see algorithm identification in the COSE RFCs. > > My opinion: I prefer the single integer. The triple is something many > COSE-using projects and protocols won’t do by default where the integer is. > > > *Ease of Coding* > Is it easier to pass an integer around or a structure? What about error > conditions and code size? > > For the integer option, some code to map the integer to the three alg > inputs to HPKE is needed. but that is not too complex and similar already > exists in COSE for things like ECDH-ES (alg -29). > > For the 3-item structure code is also needed. It will have some error > conditions that decoding a single integer won’t. > > My opinion: It’s not a big deal either way, but I prefer the single > integer, based on work in t_cose. > > > *Facilitating Algorithm Choice* > What I bring up here is how implementors and deployers will choose what > algorithm(s) to use. How will the pick from the lists of available > algorithms? > > With a single integer we’ll only define a subset of all the combo’s of > what’s possible. We can make the decision easier for many by providing > fewer choices (and if someone doesn’t like the combo we’ve defined, they > have to either go to the trouble to define a new one or use one in the > proprietary space). > > On the other hand, with the triple, the full fanout of the choice is > theirs and there is full flexibility. > > My opinion: I lean to the single integer and limited choice because I > think too much choice is not helpful or necessary and many combos don’t > make sense. That said, I can see how some want the full mix-and-match. Note > that COSE ECDH-ES already has the exactly the same fan-out problem and > seems to manage without a triple. > > > *Ease of adding a new HPKE KEM (or other alg)* > This is about what happens when we need a new KEM, say for PQ. > > With the triple, the KEM just gets registered and everything is done as > far as alg IDs and documents. There will still need to be a major SW update > for anyone to know about the new KEM. > > With the integer ID, a new integer ID must be created, documented and > registered in addition to the addition to the HPKE registry. The document > only has to be informational though. So the integer ID means some extra > registrations and an informational document. > > My opinion: Some advantages for the triple, but probably the SW update > that needs to be done no matter what sort of ID we use is a much bigger > task. Also, the number of new algorithms registered should small, like two > or three. > > LL > > > > P.S. If of interest, here’s a few of the reasons I’ve changed my mind. At > first I was interested in just getting something workable agreed upon that > wasn’t too bad. Over the last months I’ve come think more about how COSE > works as a ecosystem including COSE_Key and algorithm negotiation and came > to see the single integer as a cleaner solution. Then Orie and Christopher > Wood chimed in supporting the single integer. > > > > > > > On Jun 7, 2023, at 9:45 AM, Ilari Liusvaara <[email protected]> > wrote: > > On Wed, Jun 07, 2023 at 07:25:48AM -0500, Orie Steele wrote: > > > HPKE should work without creating new key types for dh kems, and > should work with existing APIs that currently generate keys and > envelopes based on alg. > > > The first part works, and I have written an implementation. > > The second part has _never_ worked in either JOSE nor COSE. I believe > the current record is 5 different key subtypes for one alg (for both > COSE and JOSE)! > > > A single equality check should confirm if the suite is acceptable to > the recipient, if they have a restricted key. > > > And what about check if suite is acceptable for _sender_? > > I think that barring a major flaw in HPKE, there is no need for > recipient to ever have a restricted key. Interop is separate matter, > and there can be many different supported combinations. > > > The size and expression of the alg value, should be debated, but > following the conventions and fully specifying HPKE with alg, should > be resolved first. > > > The convetion in COSE is to _not_ have ciphersuites. The some stuff > that looks a bit like ciphersuites is just size optimizations. > > > COSE HPKE will need to update registries, so let's make the minimal > updates necessary to support what the industries wants to use. > > > I think the minimum number of registry changes possible is 3. > > - A new alg > - A new header parameter > - A new key type or a reserved crv range. > > > We don't need to create new key types. > > > It is much cleaner to create a new key type than to reserve a crv > range. How is HPKE KEM 48 represented in _systematic_ manner? > > > We don't need to expose a new way to parameterize alg. > > > Doing so saves a lot of work. > > > If we don't know which alg values for COSE HPKE need to be registered, > we can wait till people show up who do. > > > What we do know is that it is either going to be a long list among time > or 1 up-front. > > > A simple RFC that follows conventions doesn't take long to update the > registry. > > > It is still unnecressary work. > > > > > -Ilari > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
