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]
