On Wed, Apr 12, 2023 at 12:31:43PM -0500, Orie Steele wrote: > TLDR; I don't support adoption of an independent key draft. > > I think COSE HPKE has problems with keys that need to be fixed, and moving > them to a separate document makes those problems worse / harder to fix. > > I am strongly supportive of the work that has gone into the hpke key draft, > and the examples and registry update requests should be included in COSE > HPKE. > > It would be sufficient to generate examples for COSE HPKE where recipient > keys signaled kem, kdf and aead, and only request registry changes > necessary to support this. > > I don't see how you can use HPKE without knowing what a recipient supports, > and I don't think it is smart to do that work in a separate document from > where it is used.
ECDH-ES in COSE and JOSE already requires use of algorithms that require off-band knowledge of support. The most prominent example is bulk encryption algorithm. KW modes are not suitable for bulk data (e.g., very slow). COSE and JOSE have multiple algorithms intended for bulk encryption (e.g., AES-GCM in at least two keysizes and CHACHA20-POLY1305). Yet, there is no way to signal support in keys. And looking at the "COSE Key Common Parameters" and "JSON Web Key Parameters" registeries, one can see neither has any mechanisms for signaling any sort support for multiple algorithms. In contrast, "hkc" does signal support for algorithms. Which makes "hkc" unprecidented. > On Wed, Apr 12, 2023 at 2:55 AM Ilari Liusvaara <[email protected]> > wrote: > > > On Tue, Apr 11, 2023 at 02:31:14PM -0500, Orie Steele wrote: > > > On Tue, Apr 11, 2023 at 2:11 PM Ilari Liusvaara < > > [email protected]> > > > wrote: > > > > > > > I think things should be split as follows: > > > > > > > > - This document will be definition of HPKE kty for COSE and JOSE. > > > > > > > > > > Seems like just adding the "kty" for HPKE to the HPKE COSE draft would be > > > better. > > > > What would define how HPKE keys are represented in JWK (there apparently > > are usecases even if there is no HPKE in JOSE)? > > > > > There may be no JWE for HPKE, but that does not mean I should be forbidden > from using a JWK with COSE HPKE. Yup, but that would still require defining how to store HPKE key in JWK. > Daisuke has provided good use cases in his presentation, recipients want to > use JWKs, because they are already using them for ECDH-ES. > > Example from the current key draft: > > { > "kty": "EC", > "kid": "01", > "crv": "P-256", > "alg": "HPKE-v1-Base", // new algorithm > "hkc": { // parameters for the algorithm, that could have been done > in the "alg" field above. > "kem": 0x010, > "kdfs": [0x001, 0x002, 0x003], > "aeads": [0x001, 0x002] > }, > "x": "-eZXC6nV-xgthy8zZMCN8pcYSeE2XfWWqckA2fsxHPc", > "y": "BGU5soLgsu_y7GN2I3EPUXS9EZ7Sw0qif-V70JtInFI" > } JOSE "alg" for HPKE would imply existence of JOSE-HPKE, and that it would work in a certain way. However, even if details of JOSE-HPKE are extremely unclear, two things seem pretty clear: - JOSE-HPKE is much harder problem than COSE-HPKE. - JOSE-HPKE will not work in the way assumed. > > > Especially since the "kty" and "hkc" are not useful by themselves. > > > > "hkc" is part of "other aspects". And I think the "kty" would be useful > > on its own. > > > > > How is the "kty" useful on its own? Can you use HPKE without a "kem id", or > without a "kdf" ? > > Please describe in great detail how this would be useful for an HPKE sender: > > { > "kty": "HPKE", // new kty, but it is for an algorithm that requires > parameters to be useful > "alg": "HPKE-v1-Base", // new algorithm, but which DHKEM is being > used?.. which kdf and aead are supported? > "x": "-eZXC6nV-xgthy8zZMCN8pcYSeE2XfWWqckA2fsxHPc", > "y": "BGU5soLgsu_y7GN2I3EPUXS9EZ7Sw0qif-V70JtInFI" > } That does not seem to be even close. Here is what HPKE JWK would look like (with >1kB public key shortened; replace JOSEisms with COSEisms for COSE_Key): { "kty": "HPKE", "kem": 48, "pub": "F1JS...WDnQ" } - Add "priv" if private key. - And as can be guessed from public key size, this is post-quantum stuff. > > Then as pointed out by L. Lundblade in IETF116 discussion, there is no > > precedent for anything like "hkc" in either JOSE or COSE. > > > > > Yes!!!!!!..... Maybe we should pause and consider the "agility thread"... > seriously. > > Perhaps JOSE and COSE have avoided exposing APIs that look like COSE HPKE, > and its implied "hkc" counterpart for good reasons. As stated above, the ECDH-ES is the most obvious precedent. There might be others. And the difficulties with JOSE-HPKE have nothing to do with "alg". The problems are with reconciling assumptions made by JWE with how HPKE operates. > I can be convinced by a good argument. > > It seems COSE HPKE violates assumptions around algorithms and keys for both > JOSE and COSE users. I do not see that HPKE violates assumptions COSE and JOSE make about keys. There already are key subtypes which work similarly to how HPKE keys would work. Regarding violating assumptions about algorithms. HPKE does not fit into any existing distribution mechanism in either COSE nor JOSE. However, COSE makes few enough assumptions about how mechanisms work to cleanly fit HPKE as a new mechanism. However, JOSE makes many more assumptions that are very diffcult to reconcile with HPKE (and if one can pull that off, the result will be quite dirty). This is the core of the problem with JOSE-HPKE. > If we are sure that the "new way" is better, let us have clear consensus > and cheers for the revolution... or maybe let's not do it. > > I would start cheering if I saw consensus around what a long term HPKE > recipient public key looks like... do we really need a separate document to > do this? > > And that is not because there is no precedent for the issue: The very > > same issue does pop up in ECDH, and seems the approach taken by both > > COSE and JOSE is to not do anything about it in keys, but leave that > > to the application profile. > > > > > See my comment at the end about COSE Key and "alg", this is what JOSE says: > > > This section defines the specifics of key agreement with Elliptic > > Curve Diffie-Hellman Ephemeral Static [RFC6090], in combination with > > the Concat KDF, as defined in Section 5.8.1 of [NIST.800-56A]. > > - https://www.rfc-editor.org/rfc/rfc7518.html#section-4.6 > - https://www.rfc-editor.org/rfc/rfc8037#section-3.2 > - https://www.rfc-editor.org/rfc/rfc7518#section-4.6.2 > <https://www.rfc-editor.org/rfc/rfc7518#section-4.6.2> > > Because "ECDH-ES+A256KW" does not have the same kind of agility as HPKE. > > You cannot change the KDF in "ECDH-ES+A256KW", so using "alg" in the JWK is > sufficient.... This appears to be a design choice that COSE HPKE disagrees > with. Yes, but which of 6 (+ obscure ones designated by URI) different bulk encryption algorithms does one use (COSE has 4)? And even if it is not cryptographically good practice, dual-use keys are also supported (as aside, X.509 requires ECDSA keys to be dual-use). Then one has no indication of KDF to use. > If I see an HPKE envelope, and I am holding an HPKE key without "hkc", the > situation is different.... No it isn't. The bulk encryption algorithm still needs to be specified. For KDF, there is usually one KDF that stands above others, but even if not, that is just another piece to specify in a similar way. > It does not need to be this way, we could make HPKE ** less revolutionary > **, and have the HPKE algorithm carry the "hkc" parameters, just like > "ECDH-ES" does.... As stated above, ECDH-ES does not carry anoything similar to "hkc" parameters, despite having algorithms that can not be bound by any means. > ... Or HPKE can stay revolutionary, and define a relation between an "alg" > and supported parameters ("hkc").... > > Why do we think it is "good agility" to generate a recipient key that > supports 3 KDF and 2 AEADs? You mean 3 KDF and 3 AEADs? The COSE-HPKE test implementation I wrote is actually capable of that. And HPKE makes it sound. And the iterim hack key format it uses certainly does not have anything like "hkc". > Is it "good agility" if a sender gets to pick which of these parameters to > use? > > Sure it's fine that the raw HPKE crypto allows this, but why register a > JOSE / COSE algorithm that REQUIRES this?... > > What is COSE HPKE doing that is useful beyond what the CFRG RFC has done > already? > > What is the COSE use case for forwarding the CRFG agility / optionality / > complexity to application developers? > > Why move this complexity to a separate document, does it not affect the > security considerations of COSE HPKE? > > > The "alg" (algorithm) parameter identifies the algorithm intended for > > use with the key. > > - https://www.rfc-editor.org/rfc/rfc7517#section-4.4 > > Let's look at some cases side by side: > > // the old way... how HPKE would look if it worked like ECHD-ES > { kty: EC, alg: HPKE-0x010-0x003-0x002 } // when I generated this key, this > is the only thing I wanted to support. > { alg: HPKE-0x010-0x003-0x002, enc: ... } // when sender encrypts to my > key, they can see what parameters I use by reviewing the "alg" field. That is not an acceptable solution. On COSE_Key side, it is even worse than HPKE-keys-in-OKP that was already deemed not acceptable. On JWK side, it makes assumptions about JOSE-HPKE that are unlikely to be true. Then there is no precedent for either: - Parsing of alg values. - Templated registrations. Registering all that stuff one by one is not acceptable. And that would still not get rid of having a new header field, because HPKE ciphertexts are not keys but existing "eph" field requires a key. > // the new way... how HPKE would look if it worked like the 2 drafts put > together > { alg: HPKE-v1-Base, "hkc": { "kem": 0x010, "kdfs": [0x001, 0x002, 0x003], > "aeads": [0x001, 0x002] } } // when I generated this key, **these** are the > only thingS I wanted to support. I do not think that is correct interpration. I think "hkc" as a capability advertisment, which means "I support these, use at will". And that list can change after key has been generated! > { alg: HPKE-v1-Base, sender_info } // when sender encrypts to my key, they > can see **all** the different parameters I use by reviewing the "alg" field > and **matching** to the parameters the sender supports that the recipient > has announced. > > Using HPKE without "hkc" or "sender info" is not possible... *** unless the > sender gets to decide and the recipient has to support everything *** > (kitchen sink). ECDH-ES already requires out-of-band information about recipient support. So HPKE without "hkc" is possible. "sender info" is required anyway due to the ciphertext-is-not-key issue. And the way "sender info" is constructed, the values in it directly map into values in HPKE itself. > If I see your key is: > > { > "kty": "EC", > "crv": "P-256", > "alg": "HPKE-v1-Base", // ... guess my sender info > "x": "-eZXC6nV-xgthy8zZMCN8pcYSeE2XfWWqckA2fsxHPc", > "y": "BGU5soLgsu_y7GN2I3EPUXS9EZ7Sw0qif-V70JtInFI" > } > > It is not enough for a sender to encrypt, > the recipient has not sufficiently described their __supported algorithm > parameters__, > the sender does not know which parameters will be supported by the > recipient... should the sender just use their preferred ones and hope for > the best? > > This can be solved for in the "alg" or in "hkc", but it can't be ignored... > AND it needs to line up with both the "envelope" and the "key". If you substitute "HPKE-v1-Base" -> "ECDH-ES+A256KW" in that example key, you sill have the exact same issue (not being able to know in-band what recipient supports), but with existing algorithms. > > > > - Any other aspects of keys in COSE (if any) go to COSE-HPKE document. > > > > > > > > > > The main thing I see in the current hpke key draft is the "hkc" > > parameter, > > > which maps directly to the IANA registries for HPKE and is also directly > > > coupled to the "alg" registry and "kty"... > > > hence my comment about just putting them in the same document. > > > > The present document mixes the kty and other aspects a lot. I think > > those should be separated. > > > > > > I don't understand how you can use the key draft without reading HPKE > > COSE > > > at this point. > > > > That's because it goes much farther than just defining the kty. > > > > Exactly, and given how HPKE works, it is not useful to only define a "kty" > for it, because such a key is not usable without the other parameters being > known. I do not think that is correct. > We already have a "kty" for the DHKEMs, it is called "EC"... ... Except the two that use "OKP". > What we don't have, is a useful "alg" for PQKEMs, or DHKEMs and the > examples we have seen all require parameters in addition to the > algorithm... in order to work. > making the algorithm alone... not sufficient to switch on... and... making > HPKE's treatment of "alg", not a "standard COSE thing". KEMs are a different and much easier problem. While direct reuse of ECDH-ES codepoints is not possible due to the ciphertext-is-not-key problem, the solution seems to be fairly obvious: - Add 'KEM+...' "alg" values to mirror existing "ECDH-ES+..." values. - Add a new header field to carry KEM ciphertext (bstr/base64url). - Rest works analogously to ECDH-ES. - Use whatever is appropriate for keys (most probably a new subtype of OKP). In JOSE, this sidesteps all the problems with JOSE-HPKE. > > > And I also don't understand how to use the "alg" parameter in HPKE COSE, > > > without defining where it goes in keys. > > > > Standard COSE rules apply. > > > > > This is not true, "sender info" is a new thing, and it is being used as a > substitute for an "alg" that normally would have carried this information, > if standard COSE / JOSE were being used. I don't see anything in COSE-HPKE that redefines how "alg" works. Nor do I think doing so would be a good idea. > Unlike 'kty: EC, alg: ECDH-ES+A256KW'... A standard COSE Key alg would not > have the parameters necessary to allow COSE HPKE sender to encrypt to > it.... > *** unless, the sender gets to pick sender info, and the recipient has to > support all the registry entries *** (kitchen sink). > > Again, if this "new way" is "better", great, we just need to explain how to > signal support for the new way in COSE Key and JWK, and I will leave it > alone : ) Well, if one wanted to add capability advertisment for HPKE. What one could do is to add a new optional _common_ key parameter that contains lists for the supported KEMs, KDFs and AEADs. In kty=HPKE, the KEM used in the key is implicitly considered supported. - Multiple KEMs are allowed, because there can be more than one possible KEM for given key (e.g., P256 vs. CP256). - Implementations can not be assumed to be able to convert raw HPKE keys, so those are assumed to be usable uncoverted. In JWK, this will not hit the "requires JOSE-HPKE" problem (if a piece of info does not make sense, just ignore it). > > > > - All work on other aspects of keys in JOSE is blocked on adopting > > > > JOSE-HPKE, and would go to that document. > > > > > > > > > > Yes, I agree that JOSE should not delay things, > > > but it seems that defining JWK representation that supports the "alg", > > > "kty" and "hpc" > > > parameters in a way similar to COSE Key, is a reasonable place to stop. > > > > Here be dragons. The major problem is that "alg" depends on how > > JOSE-HPKE works. > > Is this the first case of this for JOSE and COSE? It is. This is the first case of "alg" that is neither already defined, nor obvious on how it would work. > Does the key agreement algorithm really differ for JOSE and COSE? It does differ (for HPKE). - COSE-HPKE assumes stuff about COSE that makes straightforward port to JOSE impossilble. - And even worse, some assumptions JOSE makes seem to conflict with HPKE. E.g., the key derivation/encryption split. > If key agreement works the same, what about the other parameters, kem, kdf, > aead?... do they each work differently depending on if you use JOSE or COSE? KEM and KDF would work the same. AEAD probably would work differently. > Or are we just intentionally designing COSE HPKE (and possibly soon, HPKE > KEY) so this is the case? For COSE-HPKE itself, it is designed for COSE, and there is no consideration on how well it works with JOSE (it does not). But JWK form of HPKE key must not interact badly with JOSE (which precludes any "alg" values at this time). And one important design goal of COSE-HPKE is to be maintenance-free. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
