It’s taken a while to digest my thoughts on this discussion. I’m coming to this
as an implementer, often (but not always) in constrained devices which need to
be interoperable in complex multi-vendor deployments.
The short version is that I *strongly* prefer a single “alg” integer to further
parameterise the key usage space. The use of a construction like “hkc” is
almost certain to complicate interoperability and testing. Large-scale systems
may be able to support many options, but constrained systems rarely have that
luxury. While configuration or profile documents can help, there is generally a
risk over time of there being a large enough number of configurations that they
no longer help very much as everyone chooses his/her favourite.
I would also like to note that I don’t recommend Carsten’s “combinatorial
bitmap” approach for the same reason – it won’t scale. I have experience in
this from the GlobalPlatform TEE Internal Core APIs where we attempted to
encode information in such a bitmap and ran out of bits over time. New
algorithms *will* be added, and reserved bitfields are never wide enough.
While crypto-agility is of definite and growing importance, it is not
unreasonable to restrict the space within which agility is permitted to a
subset of the large set of possible options in the name of interoperability,
providing options that provide meaningfully different levels of security and/or
differently constructed algorithms (hence, presumably, resistant to different
classes of attack)
If the time to generate new informational RFCs to define new cipher-suites for
COSE “alg” is too long, we should address this rather than adopting “hkc” as a
workaround.
Outlook really doesn’t manage threading well, so apologies for top-posting
responses to other specific points in the thread below.
Compliance with existing standards: This is the COSE list, and I’m only
tangentially interested in JOSE, so answering for COSE. It has been stated, and
I agree that you need the key + alg to determine what to do. I believe this
remains unchanged with the single integer “alg” solution. The “hkc” solution
definitely represents a change, and does overload some concepts that are
described be existing COSE parameters – which implies even more testing for
consistency of all of the information in a COSE structure before starting to
use it.
Compatibility with design policy of other HPKE application standards: I am more
interested in maintaining COSE as a reasonably clean, consistent and
comprehensible standard. Compatibility with standards developed elsewhere falls
into the “nice to have” category for me, and is definitely secondary to the
goal of a clean COSE.
Variety of supportable use-cases: This is exactly the same with both proposals,
as far as I can tell. The difference is in the mechanism to define new
variations. I regard restricting the default set of operations as a feature and
not a bug.
>From my, possibly selfish, vendor and interoperability perspective,
>HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA256-AES128GCM and
>HPKEv1-Base-DHKEM(X25519,HKDFSHA256)-HKDFSHA256-AES128GCM do exactly the same
>thing, with near-indistinguishable levels of security, so it is not really
>clear why I would need both.
HPKE also allows me, if I understand correctly, to select
HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA384-AES256GCM – while legal, I doubt
that this represents a sensible choice for most users.
In short, this is exactly the area where I *like* to see expert review.
Ease of coding: I don’t see this as a strong argument for “alg” over “hkc”. It
is probably true that “alg” is smaller and simpler for constrained environments
as it simplifies checking in cases (common) where layering of operations is not
as clean as might be possible in a larger implementation, but this is not
really a strong justification for the approach.
In the counter-direction, the argument in favour of “hkc” as simpler from an
ease of coding perspective only applies if there is a clean separation between
the COSE and HPKE layers. For me, the essential separation is between the
description of the encoding and cryptographic libraries – it is not a given
that there needs to be a separate HPKE layer, so I don’t see it as proven that
this approach is superior.
In any case, for systems like these, the coding time for a new algorithm is far
exceeded by the time needed to complete validation to a satisfactory level.
Facilitating Algorithm Choice: I’ve worked for many years with people who
develop Trusted Applications on GlobalPlatform TEE where the cryptographic APIs
allow a great deal of flexibility. I have seen far more security errors
resulting from people choosing inappropriate cryptography than I have seen
benefit from that flexibility. There is a huge benefit in having expert
scrutiny to select a relatively small set of options that cover common
use-cases over letting people do bad things.
This means that I strongly favour simplification of usage for the 99% of users
who just want to do something secure. The 1% who have special use-cases must
certainly not be prevented from doing so, but I don’t really care if they must
deal with a slightly more inconvenient representation. In short, optimize and
guide towards for the correct usage of the common use-cases while not actively
preventing other options.
This also helps hugely with interoperability as it provides a tractable
combination of options to test (this is not a trivial factor for product
vendors).
Ease of Adding a new HPKE KEM: I don’t agree on the assumption that HPKE will
be provided as a separate layer. This will doubtless often be the case, but it
will not always be true. We certainly don’t “need” to do it.
Adding any new algorithm to a system implies change somewhere, and for the same
reason that I don’t regard “ease of coding” as an argument in favour of “alg”,
I don’t regard “ease of adding a new HPKE KEM” as an argument in favour of
“hkc”.
In particular, I expect to see increasing numbers of systems for which the
layers defined in CBOR are at least partially auto-generated from CDDL, and in
this case I think the effort would be the same.
Also important to consider that many embedded systems are essentially
statically linked and run from a single system image, so making any change
implies creating a complete new image.
Incidentally, solutions like dependabot do not address the problem of creating
adequate validation suites for cryptographic systems, and more algorithm
combinations creates a combinational explosion in the testing requirements.
Examples
Ø > 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")
Assuming we had a value of 1762 for “alg” representing
“HPKEv1-Base-DKEM(X25519,HKDFSHA256)-HKDFSHA256-AES128GCM”, I offer you:
AwesomeHPKEApp.new(alg=1762)
…which seems shorter still. I’m aware this example is facetious, but in reality
libraries would pre-define constants that an IDE would likely auto-complete for
you (even emacs does such things these days).
Best regards
Jeremy
On 11/06/2023, 03:26, "COSE" <[email protected]> wrote:
WARNING: This email originated from outside of Qualcomm. Please be wary of any
links or attachments, and do not enable macros.
I'm not attached to including aead information in "alg"... It's not in ECDH-ES.
Here is an example:
https://github.com/transmute-industries/jose-hpke/blob/main/example.json
My point is APIs expect to be able to rely on alg... To generate keys, and to
restrict what they can be used for...
alg is optional, but when it's present it should be understood.
Consider the format of ES256 signatures...
Ever wonder how to convert DER signatures to that format?... how do you know
the difference between a DER format ecdsa signature and a JOSE one?
ES256 isn't just pointing to raw crypto, it's defining what is necessary to
achieve interoperability.
JOSE HPKE interoperability isn't created by embracing the implementation cost
of supporting the entire registry.
It's created by telling implementers what is mandatory to implement.
That starts with naming popular combinations that are worth supporting.
Like ecdsa with sha256 and a signature encoding that doesn't rely asn1... We
call that ES256.
What will we call the combination of HPKE parameters that is used 99% of the
time?... Naming is hard.
OS
On Sat, Jun 10, 2023, 8:50 PM AJITOMI Daisuke
<[email protected]<mailto:[email protected]>> wrote:
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<http://island-resort.com>
<[email protected]<mailto:[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]<mailto:[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]<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
_______________________________________________
COSE mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
