Here’s the 7 non-PQ COSE-HPKE algs I’d like to see in the COSE-HPKE draft:
HPKE-P-256 (equivalent to COSE -29 with NIST key) KEM: 0x0010 DHKEM(P-256, HKDF-SHA-256) KDF: 0x0001 HKDF-SHA256 AEAD: 0x0001 AES-128-GCM HPKE-P-384 (equivalent to COSE -30 with NIST key) KEM: 0x0011 DHKEM(P-384, HKDF-SHA-384) KDF: 0x0002 HKDF-SHA384 AEAD: 0x0002 AES-256-GCM HPKE-P-521 (equivalent to COSE -31 with NIST key) KEM: 0x0012 DHKEM(P-521, HKDF-SHA-512) KDF: 0x0003 HKDF-SHA512 AEAD: 0x0002 AES-256-GCM HPKE-X25519 (equivalent to COSE -29 with Edwards curve key) KEM: 0x0020 DHKEM(X25519, HKDF-SHA-256) KDF: 0x0001 HKDF-SHA256 AEAD: 0x0001 AES-128-GCM HPKE-X448 (equivalent to COSE -31 with 448 curve key) KEM: 0x0021 DHKEM(X25519, HKDF-SHA-256) KDF: 0x0003 HKDF-SHA521 AEAD: 0x0002 AES-256-GCM HPKE-P-256-ChaCha KEM: 0x0010 DHKEM(P-256, HKDF-SHA-256) KDF: 0x0001 HKDF-SHA256 AEAD: 0x0003 ChaCha20Poly1305 HPKE-X25519-ChaCha KEM: 0x0020 DHKEM(X25519, HKDF-SHA-256) KDF: 0x0001 HKDF-SHA256 AEAD: 0x0003 ChaCha20Poly1305 It’s hard for me to see how this doesn’t cover most use cases. It’s pretty similar to the fan out in RFC 9053 (and note that the 9053 (and JOSE) fan out problem is pretty much the same as for HPKE). I don’t know much about PQ algs, but it seems we’re doing it wrong if there’s more than five or ten. Seems much better to give non-expert people (like me) a few good choices they can’t go wrong with. This is strong evidence for me that argument that the fan out will be 100+ is not very strong. I think you can also infer the bulk content encryption algorithm pretty easily. Make it AES-GCM of the same strength as AEAD. It’s pretty likely that most receivers will support most AES-GCM strengths. AES-GCM is PQ-safe so we’re not likely to change it out anytime soon. Note that all of these also specify the EC curve (unlike 9053 alg registrations) so you do NOT need additional info from the key to know the algorithm. The integer alg ID works better for COSE-HPKE than it does for the 9053 algs. There’s a lot of flexibility if this doesn’t suit your use case. The COSE IANA alg registry ranges from the private use (less than -65536) that has no requirements to a full IETF standard. Note that the recent Chinese algorithm registration was content with specification required. I would expect final agreed-upon HPKE PQ algorithms would come in as informational RFCs since HPKE and RFC 9053 are informational. For something as important as this, I would think the informational RFC process is about the right level. There should be a good public discussion and agreement. LL On Jul 5, 2023, at 2:51 AM, Jeremy O'Donoghue <[email protected]<mailto:[email protected]>> wrote: Hi Ilari, Response inline below – apologies once more for Outlook threading. I’m not seeing convergence to consensus in this thread. At this point it seems that we have one group definitely favouring “alg” and another group definitely favouring “hkc”, and it seems like no-one is changing their mind at this point because there are strong technical arguments on both sides. Perhaps it is better for WG chair to get a feel for where wider group opinion lies – we have maybe six or seven people expressing strong opinions in one direction or another in a group that doubtless has a much larger number of contributors. Even the “+1” for one or other approach from a broader range of people in the group would be very helpful at this point, I think. Jeremy On 29/06/2023, 21:41, "COSE" <[email protected]<mailto:[email protected]>> wrote: WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. On Thu, Jun 29, 2023 at 04:00:09PM +0000, Jeremy O'Donoghue wrote: > 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. There has *never* been "single alg parameter" in COSE. Even in stock RFC 8152, Message recipients can involve *three* different alg parameters (+ fourth thing). [JOD] “hkc” still complicates things further. As an implementer, checking the consistency and compatibility of COSE arguments is already fairly tedious – adding a special case makes things significantly worse. I’m strongly with Laurence on this point. And "hkc" is not meant for highly constrained cases. For example, if application does ciphersuite-per-key-type, then "hkc" is completely unnecressary. [JOD] HPKE is not for constrained use-cases? I can think of constrained use-cases. This seems like a bold claim to make. In many cases, particularly if you care strongly about security in an Edge device, you will want your COSE implementation to sit in a small Enclave/TEE that communicates with a Root of Trust that holds the crypto keys and hardware – these are commonly pretty constrained environments – a Arm Cortex M class device with Trustzone-M or an equivalent RISC-V MCU, with low-hundreds of kiB memory. And having explicit list would do absolutely nothing to help interop in constrained environments. The list would probably cover every KEM, KDF and AEAD in HPKE at least once. Which would require the same effort as dealing with everything. Except with *additional* complexity of dealing with coupling. [JOD] I think this is just a question of where you put the complexity. In a constrained environment you would likely use a profile to constrain the supported algorithm choices. As an example, it is much easier to deal with TLS 1.3 crypto negotiation compared to TLS 1.2 crypto negotiation. Not because there are less choices, but because there is much less coupling. [JOD] <snip> > 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) This does not actually help interoperability. Then, COSE has always been frameworky. For such specifications, restrictions for interop are inapporiate. Instead, the specs are intended to be profiled down or specialized for applications, and in that process, appriate restrictions are defined for interoperability. [JOD] I agree that profiles are needed regardless of solution. “alg” and “hkc” are proposing different ways to do the same thing, placing the effort in slightly different places. <snip> > 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. It is not just one RFC (and that is surprising amount of effort), but essentially endless stream of those, every time HPKE adds something, and those costs add up. [JOD] I am aware of the effort in producing an RFC. What I have seen is that large framework RFCs that define something new take a long time (some of us on this list are editors of the RATS EAT draft, for example, so well aware of this). I have also observed that RFCs which extend an existing framework in specific and limited ways can be published fairly quickly. It is probably true that the “alg” approach may require two RFCs rather than one if making HPKE changes, but this reflects that anyway if you are potentially changing how COSE works (as here), consensus is needed in the COSE WG before this can be adopted. <snip> > 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. No, it is not the same. More work for extra complexity, for likely no gain. [JOD] I’m personally happy to put more work/complexity on the 1% that have particular and specialized needs compared to the 99% who do not, as previously stated. I can’t see that “alg” makes anything impossible, merely more work, although later in thread you suggest that it does. <snip> > In short, this is exactly the area where I *like* to see expert > review. That review is going to be less "expert" than what you would like... [JOD] Disappointing, if true. <snip> > 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). As I explained above, it does not help with interoperability. And with regards to testing, it would *increase* the effort required. [JOD] As a vendor, I will certainly test layers independently in unit testing, but I will also extensively test *all* supported options before I ship. > 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. HPKE is certainly *specified* as a separate layer. While yeeting the parts of HPKE that are never used gets good simplifications, I think it is doubtful that mixng in the HPKE implementation will buy much, as most of that is irreducable crypto code. [JOD] It should reduce parameter checking code. While this is often not very much compiled code, it is easy to get wrong. > 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”. That change can be just updating the HPKE library. Something that is required anyway. [JOD] Assumes that you can update libraries individually. This is usually not true for enclaves where static bootable images are more common. Once you have to generate a new image, there is no benefit to enforced separation. > 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. CDDL might autogenerate a parser, but it definitely will not autogenerate a decoder. [JOD] Agreed. However parser-generator code could very well contain productions that drive the crypto libraries, and these would rarely change – this is the case I consider to be the same effort. <snip> > 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. That does not mean it is irrelevant how many components need to be modified: Builds are automated, modifying components is not. > 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. How testing requirements scale depends on coupling. That combinatorial explosion *only* happens in presence of coupling. [JOD] As noted above, I will not ship anything before testing all of the combinations I support in my implementation. > 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). Well, there are some issues with that API, starting from the fact that KEM is constrained by the key... [JOD] My apologies. I misattributed the original examples above to you. I had to follow the message threading by date to verify that it didn’t originate in any of your mails. My general point is that there are lots of ways to design an API. -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] https://www.ietf.org/mailman/listinfo/cose
