Illari, Orie, and Mike P, could you please confirm if your comments have been addressed in the latest version of the draft draft-reddy-cose-jose-pqc-hybrid-hpke <https://datatracker.ietf.org/doc/html/draft-reddy-cose-jose-pqc-hybrid-hpke> ?
-Tiru On Mon, 9 Dec 2024 at 15:53, tirumal reddy <[email protected]> wrote: > Hi all, > > I have published a revised draft ( > https://www.ietf.org/archive/id/draft-reddy-cose-jose-pqc-hybrid-hpke-05.html), > which addresses all comments raised, particularly from Orie and Ilari. The > draft appears ready for adoption. > > Cheers, > -Tiru > On Fri, 6 Dec 2024 at 15:36, tirumal reddy <[email protected]> wrote: > >> Hi Orie, >> >> I raised a PR https://github.com/tireddy2/Hybrid-KEM-with-COSE-JOSE/pulls >> to use "AKP". >> >> Cheers, >> -Tiru >> >> On Thu, 5 Dec 2024 at 04:05, Orie Steele <[email protected]> >> wrote: >> >>> Changing "crv" is indeed not possible at this point.... but we are not >>> required to use "crv" to express pqc or hybrid keys. >>> >>> The document that enables an "alg" to be used in a message can also >>> specify which "kty" and other parameters are required to be present when >>> that alg is expressed in a key. >>> >>> We are comparing: >>> >>> ### Option A >>> >>> const jwk = { >>> kty: "AKP", // mandatory >>> alg: "X-Wing", // mandatory >>> pub: "4iNrNajCSz...tmrrIzQSQQO9lNA", // mandatory >>> priv: "f5wrpOiP...rPpm7yY", // mandatory >>> }; >>> >>> ### Option B >>> >>> const jwk = { >>> kty: "OKP", // mandatory >>> crv: "X-Wing", // mandatory >>> alg: "X-Wing", // optional >>> x: "4iNrNajCSz...tmrrIzQSQQO9lNA", // mandatory >>> d: "f5wrpOiP...rPpm7yY" // mandatory >>> }; >>> >>> I'm saying let's go with Option A. >>> >>> >>> On Wed, Dec 4, 2024 at 4:22 PM Sophie Schmieg <[email protected]> >>> wrote: >>> >>>> I would really like to avoid a reality where someone uses the separate >>>> parts of an X-Wing key in their own primitives, that way lies madness and >>>> vulnerabilities. COSE should treat hybrids just like any other algorithm, >>>> and pretend to not know anything about how the opaque blob of bytes >>>> operates. >>>> As for unfortunate naming decisions, there is some precedent here, with >>>> TLS calling everything a group. Kind of unfortunate and "algorithm >>>> parameter" or similar would have been the far better term for it, but I >>>> somewhat assume that changing this name at this point is infeasible. (An >>>> overly pendadic person might point out though, that Z[X]/(X^256+1)^3 is, as >>>> a module of a number field order, by definition still a group, and that >>>> Z[X](X^256+1) has Dedekind dimension one, which means that it would be fair >>>> to say that at least Spec Z[X]/(X^256+1) is a curve, so we are still >>>> talking about a vector bundle over a curve) >>>> >>>> On Wed, Dec 4, 2024 at 6:25 AM tirumal reddy <[email protected]> wrote: >>>> >>>>> Thanks Orie for valuable inputs, raise PRs for both the drafts, see >>>>> https://github.com/tireddy2/Hybrid-KEM-with-COSE-JOSE/pull/4 >>>>> and >>>>> https://github.com/ietf-wg-jose/draft-ietf-jose-hpke-encrypt/pull/11. >>>>> >>>>> On Tue, 3 Dec 2024 at 20:08, Orie Steele <[email protected]> >>>>> wrote: >>>>> >>>>>> Sure, but that is a problem for: >>>>>> >>>>>> https://datatracker.ietf.org/doc/draft-ietf-cose-hpke/ >>>>>> https://datatracker.ietf.org/doc/draft-ietf-jose-hpke-encrypt/ >>>>>> >>>>>> Consider what the example you gave above means in a pre-hpke world: >>>>>> >>>>>> { >>>>>> "kty": "OKP", >>>>>> "crv": "X25519", >>>>>> "algorithms": ["ECDH-ES+A128KW", "ECDH-ES+A256KW"], >>>>>> "x": "KIWi1p4buN7...N8zkhfF8pGs", >>>>>> } >>>>>> >>>>>> The algorithms in the key are for key establishment / key wrapping... >>>>>> not content encryption. >>>>>> >>>>>> HPKE is adding the idea of enabling "direct integrated encryption". >>>>>> ... and in doing so, enabling you to use a key wrapping algorithm >>>>>> which is also a content encryption algorithm and which is an hpke aead. >>>>>> If that's a bad idea, we are not making it better by adding PQ/T >>>>>> hybrids to it, or enabling multiple HPKE suites to be used for the same >>>>>> KEM >>>>>> key. >>>>>> >>>>>> https://datatracker.ietf.org/doc/html/rfc9180#name-kem-key-reuse >>>>>> >>>>>> So while HPKE might allow the same kem key to be used with multiple >>>>>> AEADs, there is no reason that JOSE and COSE should allow it... >>>>>> *Because this use case is solved for in the 2 layer constructions in >>>>>> JOSE and COSE.* >>>>>> >>>>>> I consider it to be a bad idea to advertise multiple key encryption / >>>>>> key wrapping algorithms for a single kem key pair. >>>>>> >>>>>> Let's look at a complete example of X-Wing in JOSE starting with the >>>>>> recipient public key: >>>>>> >>>>>> { >>>>>> "kty": "AKP", >>>>>> "kid": >>>>>> "urn:ietf:params:oauth:jwk-thumbprint:sha-256:S6AXfdU_6Yfzvu0KDDJb0sFuwnIWPk6LMTErYhPb32s", >>>>>> "alg": "HPKE-XWING-SHA256-A256GCM", >>>>>> "pub": "KIWi1p4buN7...N8zkhfF8pGs", >>>>>> "priv": "i20zlCBQr0...JsShVkf3q4qUc" >>>>>> } >>>>>> >>>>>> ^ such a key can be used for both integrated encryption and 2 key >>>>>> encryption in both JOSE and COSE. >>>>>> >>>>>> You can encrypt directly to this key using A256GCM, >>>>>> and indirectly by using HPKE-XWING-SHA256-A256GCM to encrypt a >>>>>> content encryption key, and then using any of the algorithms registered >>>>>> here: >>>>>> >>>>>> >>>>>> https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms >>>>>> ... that support "enc" ... (ChaCha20Poly1305 is not in this registry >>>>>> btw). >>>>>> >>>>>> ## Integrated Encryption (X-Wing HPKE JWT) >>>>>> >>>>>> { >>>>>> "protectedHeader": { >>>>>> "alg": "HPKE-XWING-SHA256-A256GCM", >>>>>> "enc": "dir", >>>>>> "kid": " >>>>>> urn:ietf:params:oauth:jwk-thumbprint:sha-256:S6AXfdU_6Yfzvu0KDDJb0sFuwnIWPk6LMTErYhPb32s >>>>>> " >>>>>> }, >>>>>> "payload": { >>>>>> "urn:example:claim": true, >>>>>> "iss": "urn:example:issuer", >>>>>> "aud": "urn:example:audience", >>>>>> "iat": 1729785491, >>>>>> "exp": 1729792691 >>>>>> } >>>>>> } >>>>>> >>>>>> ## Key Encryption (Multiple recipients, using the same content >>>>>> encryption algorithm) >>>>>> >>>>>> { >>>>>> "protected": "eyJlbmMiOiJBMTI4R0NNIn0", // { "enc" : "A128GCM" } >>>>>> "iv": "ZL0HDvZJizA6vyTV", >>>>>> "ciphertext": "Oq26x9vppULrGNzCn2j...BgQpgJPchg0eWNmgv4Ozi5I", >>>>>> "tag": "ULnlOiJRYfCzM_r5j9sLEQ", >>>>>> "aad": "cGF1bCBhdHJlaWRlcw", >>>>>> "recipients": [ >>>>>> { >>>>>> "encrypted_key": "G3HmlpOgA4H...w7svDwUqvNR", >>>>>> "header": { >>>>>> "kid": "urn:ietf:params:oauth:jwk-thumbprint:sha-256: >>>>>> cxQC_lWt22BIjH5AWSLHCZk_f-mU3-W4Ztcu5-ZbwTk", >>>>>> "alg": "ECDH-ES+A128KW", >>>>>> "epk": { >>>>>> "kty": "OKP", >>>>>> "crv": "X25519", >>>>>> "x": "JnGWSQ90hlt0H7..._Dn_CkLzE", >>>>>> } >>>>>> } >>>>>> }, >>>>>> { >>>>>> "encrypted_key": "pn6ED0ijngCiWF8...mRF7QarTVfuWj6dw", >>>>>> "header": { >>>>>> "alg": "HPKE-XWING-SHA256-A256GCM", >>>>>> "kid": >>>>>> "urn:ietf:params:oauth:jwk-thumbprint:sha-256:S6AXfdU_6Yfzvu0KDDJb0sFuwnIWPk6LMTErYhPb32s", >>>>>> "ek": >>>>>> "BI41YDnhTTI6jSd7T62rLwzC...X9UXDw_3ylbXTiYWmPXl2fNmr4BeQ" >>>>>> } >>>>>> } >>>>>> ] >>>>>> } >>>>>> >>>>>> Some comments on kem key reuse: >>>>>> >>>>>> In the example above, assume the X25519 ECDH-ES+A128KW part is to >>>>>> the x25519 component of the X-Wing key. >>>>>> When a CRQC breaks ECDH-ES, the encrypted content encryption key is >>>>>> broken, and the attacker can ignore x-wing completely, and still recover >>>>>> the plaintext. >>>>>> This remains true when any recipient in a 2 layer uses any of the >>>>>> traditional 2 layer algorithms in the JOSE and COSE registries today >>>>>> (except for psk stuff mixed into kdfs). >>>>>> >>>>>> In the case of direct encryption to the x25519 component of an x-wing >>>>>> key, the plaintext is also recovered. >>>>>> >>>>>> The only way to protect against both modes is to use X-Wing for both >>>>>> integrated encryption and key encryption and to always use the full >>>>>> x-wing >>>>>> algorithm with a given x-wing key, and in the case of multiple >>>>>> recipients, >>>>>> to ensure that each recipient is using a PQ key encryption / key wrapping >>>>>> algorithm.... because in 2 layer breaking a single recipient encrypted >>>>>> content encryption key recovers plaintext. >>>>>> >>>>>> OS >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Dec 3, 2024 at 6:57 AM tirumal reddy <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Thanks Orie for the detailed explanation. I understand your >>>>>>> suggestion to use "AKP" instead of "OKP," but "AKP" has limitations, >>>>>>> particularly with the HPKE PQ/T scheme. For example, in the HPKE, a >>>>>>> single >>>>>>> key agreement mechanism can be paired with multiple AEAD algorithms, >>>>>>> resulting in unique cryptographic algorithm identifiers. For instance: >>>>>>> >>>>>>> - HPKE-XWING-SHA256-ChaCha20Poly1305 >>>>>>> - HPKE-XWING-SHA256-AES256GCM >>>>>>> >>>>>>> To address this, the key type "AKP" would need to be extended to >>>>>>> accommodate multiple algorithms. A possible JSON representation could >>>>>>> look >>>>>>> like this: >>>>>>> >>>>>>> { >>>>>>> "kty": "AKP", >>>>>>> "kid": "01", >>>>>>> "algorithms": [ >>>>>>> "HPKE-XWING-SHA256-ChaCha20Poly1305", >>>>>>> "HPKE-XWING-SHA256-AES256GCM" >>>>>>> ], >>>>>>> "key_ops": [ >>>>>>> "deriveBits", >>>>>>> "wrapKey" >>>>>>> ]} >>>>>>> >>>>>>> -Tiru >>>>>>> >>>>>>> On Tue, 3 Dec 2024 at 02:25, Orie Steele <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> https://author-tools.ietf.org/iddiff?url1=draft-reddy-cose-jose-pqc-hybrid-hpke-03&url2=draft-reddy-cose-jose-pqc-hybrid-hpke-04&difftype=--hwdiff >>>>>>>> >>>>>>>> Further comments: >>>>>>>> >>>>>>>> X-Wing is not an Elliptic Curve. >>>>>>>> >>>>>>>> X-Wing keys using OKP and (ab)using the "crv" parameter to mean >>>>>>>> "curve with parameters + lattice with parameters"... is something I >>>>>>>> really hope we can decide not to do. >>>>>>>> >>>>>>>> As I said in >>>>>>>> https://mailarchive.ietf.org/arch/msg/cose/LMh6LpT5aqF5m47dmQ_roWU18eM/ >>>>>>>> >>>>>>>> It would be nice to agree to use keys for algorithms, and to use >>>>>>>> AKP for ML-KEM and ML-DSA, and X-Wing with HPKE, and X-Wing without >>>>>>>> HPKE... >>>>>>>> and all of this is possible with the use of the AKP key type with fully >>>>>>>> specified algorithms. >>>>>>>> >>>>>>>> >>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-cose-dilithium-04#name-algorithm-key-pair-type >>>>>>>> >>>>>>>> Obviously I disagree with Ilari on this point. >>>>>>>> .... however, I hope we can agree that whatever we do for ML-DSA, >>>>>>>> it will work for ML-KEM and X-Wing, and HPKE... or whatever CRFG comes >>>>>>>> up >>>>>>>> with next. >>>>>>>> >>>>>>>> *In summary, it's nice that the HPKE algorithms have been added, >>>>>>>> but I object to the key representation using OKP.* >>>>>>>> >>>>>>>> Motivation for my objection to the use of OKP for ML-KEM keys: >>>>>>>> >>>>>>>> Consider that OKP is commonly considered reserved for "elliptic >>>>>>>> curve points", as noted in >>>>>>>> https://datatracker.ietf.org/doc/html/rfc8152#section-12.4.2 >>>>>>>> >>>>>>>> https://www.rfc-editor.org/rfc/rfc8037.html#section-2 >>>>>>>> >>>>>>>> Note: Do not assume that there is an underlying elliptic curve, >>>>>>>> despite the existence of the "crv" and "x" parameters. (For >>>>>>>> instance, this key type could be extended to represent >>>>>>>> Diffie-Hellman >>>>>>>> (DH) algorithms based on hyperelliptic surfaces.) >>>>>>>> >>>>>>>> It does not matter how many times I read the note above, the >>>>>>>> normative MUST says: >>>>>>>> >>>>>>>> o The parameter "crv" MUST be present and contain the subtype of >>>>>>>> the >>>>>>>> key (from the "JSON Web Elliptic Curve" registry). >>>>>>>> >>>>>>>> This means we are required to put things that are not curves in a >>>>>>>> registry for curves.... >>>>>>>> >>>>>>>> If the algorithm param "alg" is not mandatory for an X-Wing key, >>>>>>>> can I use the same key for ML-KEM and X25519 and X-Wing? >>>>>>>> Do I have to put "alg" in the key, even though it's optional (in >>>>>>>> OKP) to signal a safer use pattern? >>>>>>>> If I encrypt with X25519 to an X-Wing key that has no "alg" >>>>>>>> parameter, what happens?... is it ok, if I use the X25519 component to >>>>>>>> decrypt? it works... is this legal? >>>>>>>> >>>>>>>> { >>>>>>>> "kty": "OKP", >>>>>>>> "crv": "X-Wing", // not a curve... just means x and d cannot >>>>>>>> be validated... unless you know the intended algorithm >>>>>>>> "alg": "ECDH-ES+A128KW", // HPKE-XWING-SHA256-AES256GCM >>>>>>>> // HPKE-X25519-SHA256-CHACHA20POLY1305 >>>>>>>> "x": "KIWi1p4buN7...N8zkhfF8pGs", // 2 public keys >>>>>>>> "d": "i20zlCBQr0...JsShVkf3q4qUc" // 2 private keys or a >>>>>>>> single seed for both private keys >>>>>>>> } >>>>>>>> >>>>>>>> The thumbprints will be different ... >>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-cose-key-thumbprint-06#name-octet-key-pair-okp >>>>>>>> >>>>>>>> Even if the same private key can decrypt messages to each public >>>>>>>> key that contains "somewhere (no validation)" the necessary >>>>>>>> components.... >>>>>>>> The thumbprint for a hybrid public key should include the algorithm >>>>>>>> used to construct the hybrid, not just the public keys used with any >>>>>>>> component algorithms or the hybrid. >>>>>>>> >>>>>>>> Either we should scrap the AKP concept and use OKP as Ilari >>>>>>>> suggested. >>>>>>>> ... or we should not use OKP for new "subtype"s... and especially >>>>>>>> not for hybrids. >>>>>>>> >>>>>>>> I don't know if this comment should gate working group adoption, >>>>>>>> but it certainly seems it should gate a WGLC for either document that >>>>>>>> references ML-KEM / ML-DSA . >>>>>>>> Thanks to Russ, Neil and others who gave WGLC feedback on AKP and >>>>>>>> ML-DSA for JOSE and COSE, I am tracking your comments here: >>>>>>>> https://github.com/cose-wg/draft-ietf-cose-dilithium/issues but >>>>>>>> have not yet addressed them. >>>>>>>> >>>>>>>> Ilari, Hannes and Tiru, please feel free to file a WGLC comment on >>>>>>>> the use of AKP in ML-DSA. >>>>>>>> >>>>>>>> Whatever the outcome, there should be alignment on seeds, private >>>>>>>> keys, public keys and algorithms for lattice and hybrid PQC (ML-DSA / >>>>>>>> ML-KEM / X-Wing) >>>>>>>> >>>>>>>> "pub" is better than "x" >>>>>>>> >>>>>>>> "priv" is better than "d" >>>>>>>> >>>>>>>> "alg" should have been mandatory in keys, >>>>>>>> ... and forbidden in headers ( a ship that has sailed, and can't be >>>>>>>> fixed for EC2 / OKP keys, or JWE / COSE Encrypt envelopes )... >>>>>>>> >>>>>>>> *...things that are not elliptic curves do not belong in a >>>>>>>> registry for elliptic curves...* >>>>>>>> >>>>>>>> I will die on these hills. If I'm in the rough, it would be good to >>>>>>>> know. >>>>>>>> >>>>>>>> OS >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Dec 2, 2024 at 11:11 AM Michael Jones < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Ilari, Orie, and Mike P., do you believe that your comments on the >>>>>>>>> previous draft have been addressed in this one? If not, what further >>>>>>>>> changes would you suggest? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks all, >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Mike >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *From:* tirumal reddy <[email protected]> >>>>>>>>> *Sent:* Monday, December 2, 2024 5:29 AM >>>>>>>>> *To:* Michael Jones <[email protected]> >>>>>>>>> *Cc:* [email protected] >>>>>>>>> *Subject:* Re: [COSE] Re: Call for adoption of >>>>>>>>> draft-reddy-cose-jose-pqc-hybrid-hpke >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The revised draft >>>>>>>>> https://www.ietf.org/archive/id/draft-reddy-cose-jose-pqc-hybrid-hpke-04.html >>>>>>>>> addresses all the comments raised during the WG adoption call. >>>>>>>>> Regarding >>>>>>>>> Michael's comment on the terms 'traditional' and 'Post-Quantum,' this >>>>>>>>> issue >>>>>>>>> has been discussed in the PQUIP WG. However, no decision has been >>>>>>>>> made to >>>>>>>>> change the terminology, and this issue is beyond the scope of this >>>>>>>>> document >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -Tiru >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, 30 Nov 2024 at 22:42, Michael Jones < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>> Only two replies to the call for adoption clearly stated that they >>>>>>>>> favored adoption. Whereas more messages were sent than that with >>>>>>>>> critiques >>>>>>>>> of the draft. Therefore, the draft is not adopted in its present >>>>>>>>> form. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The chairs suggest that the authors update the specification to >>>>>>>>> address the feedback from Ilari, Orie, Mike P., and Michael R. and >>>>>>>>> publish >>>>>>>>> a new draft, and then ask for feedback on the revised draft on the >>>>>>>>> mailing >>>>>>>>> list. Following that, we can consider a call for adoption of the >>>>>>>>> revised >>>>>>>>> draft. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> For the chairs, >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Mike >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *From:* Michael Jones >>>>>>>>> *Sent:* Friday, November 8, 2024 7:04 AM >>>>>>>>> *To:* [email protected] >>>>>>>>> *Subject:* Call for adoption of >>>>>>>>> draft-reddy-cose-jose-pqc-hybrid-hpke >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Per discussions at the IETF 121 COSE working group meeting, this >>>>>>>>> note starts a two-week call for adoption of the PQ/T Hybrid KEM: HPKE >>>>>>>>> with >>>>>>>>> JOSE/COSE specification. Please let us know whether you are in favor >>>>>>>>> of >>>>>>>>> adoption or not by Friday, November 22, 2024. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Mike & Ivo >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> COSE mailing list -- [email protected] >>>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> COSE mailing list -- [email protected] >>>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> ORIE STEELE >>>>>>>> Chief Technology Officer >>>>>>>> www.transmute.industries >>>>>>>> >>>>>>>> <https://transmute.industries> >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> ORIE STEELE >>>>>> Chief Technology Officer >>>>>> www.transmute.industries >>>>>> >>>>>> <https://transmute.industries> >>>>>> >>>>> _______________________________________________ >>>>> COSE mailing list -- [email protected] >>>>> To unsubscribe send an email to [email protected] >>>>> >>>> >>>> >>>> -- >>>> >>>> Sophie Schmieg | Information Security Engineer | ISE Crypto | >>>> [email protected] >>>> >>>> >>> >>> -- >>> >>> >>> ORIE STEELE >>> Chief Technology Officer >>> www.transmute.industries >>> >>> <https://transmute.industries> >>> >>
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
