(Sorry Krull dimension 1, Dedekind is what the domains are named after) On Wed, Dec 4, 2024 at 2: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] > > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | [email protected]
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
