Thanks for the review! Responses inline: On Wed, Aug 17, 2022 at 8:51 AM Ilari Liusvaara <[email protected]> wrote:
> On Tue, Aug 16, 2022 at 08:29:53AM -0700, [email protected] wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the CBOR Object Signing and Encryption WG > of the IETF. > > > > Title : JOSE and COSE Encoding for Post-Quantum > Signatures > > Authors : Michael Prorock > > Orie Steele > > Rafael Misoczki > > Michael Osborne > > Christine Cloostermans > > Filename : draft-ietf-cose-post-quantum-signatures-00.txt > > Pages : 36 > > Date : 2022-08-16 > > > > Abstract: > > This document describes JSON and CBOR serializations for several post > > quantum cryptography (PQC) based suites including CRYSTALS Dilithium, > > Falcon, and SPHINCS+. > > > > Trying to review this: > > - Dilithium (v3.1) keys are abstract signature keys. They are _not_ LWE > keys. And if one wants dedicated key type for implementations to > dispatch on, the name should refer to Dilithium, not to "LWE". > > I don't think we agree regarding how `kty` is interpreted. - https://www.iana.org/assignments/jose/jose.xhtml - https://www.rfc-editor.org/rfc/rfc7518.html#section-6.1 - https://www.rfc-editor.org/rfc/rfc7517#section-4.1 The "kty" (key type) parameter identifies the cryptographic algorithm family used with the key, such as "RSA" or "EC". "cryptographic algorithm family" <- I believe this is where the breakdown is occuring. If you think an "algorithm family" is built on a cryptographic building block like RSA, EC, LWE, NTRU, one way functions in the random oracle model, etc.... you come to one conclusion. If you think an "algorithm family" is built on a specific hard problem with a set of internalized parameters you come to a different conclusion, and your "key types" end up looking like "curve names" or "lattice names" or "hash based system names". For example: kty: EC, crv: P-256, alg: ES256 -> "ECDSA using P-256 and SHA-256" - https://www.rfc-editor.org/rfc/rfc7518#section-3.1 Let's look at the Dilithium paper: https://eprint.iacr.org/2017/633.pdf "It can be shown that in the (classical) random oracle model, Dilithium is SUF-CMA secure based on the hardness of the standard MLWE and MSIS lattice problems." In a lattice based system, this corresponds to: kty: LWE (hardness problem family), alg: CRYDI3 (parameters on the hardness problem). - I can't make heads or tails of the use of the "pset" parameter. "alg" > already fully specifies the variant, there is nothing further to > specify. > > That's correct, "pset" comes from the paper see "Table 2: Parameters for Dilithium.". We've encoded these parameters in an "alg" similar to the approach noted above for P-256. > - The pset talks about alg "CRYDI", but the above table gives exhaustive > list of valid algorithms that does not include "CRYDI". > > I suspect this is an error in the draft... the intention is to not need to register a new term called "pset" and instead register new `alg` values to encode the parameters defined by NIST. > - The COSE key type is listed as PQK. Either that should be something > generic for abstract signature key, or something specific for > Dilithium if implementers want to dispatch on that. > > I suspect this is an error in the draft... When last we asked this list there seemed to be an objection to defining a `kty` for the entire family of "post quantum algorithms". > - The way message is hashed inside Dilithium resembles the way the > RSA-PSS submission did message hashing. However, RSA-PSS changed the > message hashing for the final version. If similar change happens in > final version of Dilithium, that has extremely nasty effect on the > way Dilithium is integrated into COSE and JOSE (basically meaning > everything has to be redone). > > We are planning to hurry up and wait for NIST to finalize... I don't see this as a concern. If we need to register additional `alg` values we can. > - The Dilithium team does not recommend using Dilithium the way it is > used in the draft (they recommend hybridization). > > Do you have a source for this comment? Regardless, this draft is not targeting hybrid / composite schemes. That work can happen in parallel if folks want to attempt it. > - I do not think Dilithium should be used at all at this point. Use > either ECC and SPHINCS+ depending on how difficult updating to PQC > later is. > > We are not here to argue over if Dilithium, Falcon or SPHINCs should be used... we are here to define key and signature encodings for them, in the case that folks have already decided they want to use them... and they want to be understood consistently. > > - Falcon (v1.2) keys are abstract signature keys. They are _not_ NTRU > keys. And if one wants dedicated kty for dispatch, that should refer > to Falcon, not to "NTRU". > > Same comment as above. > - Again, there is the "pset" parameter I can not make heads or tails > about. After alg there is nothing further to specify. > > Same comment as above. Agree, `alg` is all that is needed to switch on, when it communicates the key family and parameters fully. For example, ES256 tells you all you need to know, "ECDSA using P-256 and SHA-256". > - The pset talks about alg "FALCON", which is not in exhaustive table of > algorithms. > > I suspect this is an error in the draft... or there is confusion about the function of the `kty` + `alg` table. > - FALCON also uses hashing that resembles RSA-PSS submission. If that > gets changed similarly to RSA-PSS in the final version, the > consequences are similar as in Dilithium case. > > Same comment as above, we will address this in the definition of the `alg` values we register. We should not attempt to finalize the registrations until we are confident that we know the parameters that will be used. - The COSE key type is also "NTRU", which differs from Dilithium. Either > it should be generic type, or some type referencing FALCON. > > Are you suggesting we register a generic kty: PQK? or kty: LATTICE ? What is your definition of a "cryptographic algorithm family" ? > - Even if there are no obvious recommendations from FALCON team about > its use, I think using it unhybrized at this point is bad idea. > > I disagree, at IETF114 composite / hybrid approaches received tremendous pushback... This draft is not attempting to address "hybrid or composite schemes"... at all. > - The comment about should not use Dilithium also appiles to FALCON. > (Basically, use ECC or SPHINCS+). > > Again, we are not here to recommend or "pick winners"... we are here to explain how to represent the choices made by NIST. > - The reason both Dilithium and FALCON were selected for standardization > is that the smaller size of FALCON comes at very high cost: FALCON > requires double-precision floating-point hardware to run decently, > something many constrained systems lack. It is also much much harder > to implement than Dilithium. Worse, any implementation errors likely > lead to private key being leaked. > > > I agree with this comment, but it applies more to the "raw cryptography layer"... not the JSON or CBOR encodings. > - SPHINCS+ keys are abstract signature keys. They are not any kind of > "hash-based signature" keys. Any dedicated type should refer to > SPHINCS+, not to "HASH". > > Same comment as before, I don't think we agree regarding consistent interpretation of `kty`. > - What hash function is used? SPHINCS+ specifies SHA-2, SHAKE and > one other fly-by-night hash. The choices are all incompatible with > one another. > > The `alg` label will be used to specify this. We can register more than one `alg`, similar to Dilithium parameters sets. > - Again, there is the "pset" parameter I can not make heads or tails > about. After alg there is nothing further to specify. > > Agree, same comment as before, `alg` is meant to identify a particular collection of parameters, for example "ECDSA using P-256 and SHA-256". > - Text talks about alg "HAS", but the above exhaustive table does not > list that. > > "kty: HASH alg: SPHINCS+128s" You can imagine another suite similar to sphincs, relying on hashing, but using a different algorithm and a different hash function. The kty would be "HASH", the alg would be something different... that reflected the chosen parameters. - The COSE key type is also "HASH", which differs from Dilithium. Either > it should be generic type, or some type referencing SPHINCS+. > > > Same comment as before, are you suggesting you prefer kty: PQK? > > - What is KeyValidate? > This is a spec error, it's left over from earlier versions where we focused much more on the specifics of dilithium. This is the closest analog from existing RFCs: https://www.rfc-editor.org/rfc/rfc7517#section-9.1 There are cases where you might wish to validate the key representation, before attempting to use it for a verification or a signature... that's out of scope for a serialization spec such as this imo. > > - The security considerations mentions Dilithium, but does not even > mention the extreme care required in implementing FALCON. > > Yes, in general the security considerations section needs a lot of work, however, this is not the right spec to speak to considerations that are not directly related to JSON or CBOR encodings. We will likely want to point to other references, similar to: https://www.rfc-editor.org/rfc/rfc7517#section-9.2 > - What "nonces" is section 7.3 talking about? > > > I believe this is a spec error, left over from the boilerplate we used. > > > -Ilari > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
