Hi Orie, I dunno about the new/old thing. CMS/PKCS is old and it doesn’t use ciphersuites. :-) I took COSE’s use of ciphersuites to be new and enlightened because: - Only a small percentage of the fan out is sensible - Us experts limit the choices to the sensible ones making it easier for non-expert deployment - Fewer bytes on the wire and a little less code - Much smaller test and validation fan out. For example https://github.com/gluecose/test-vectors will be much larger without suites
If one part of a ciphersuite is found to be weak, you don’t throw out the whole car, you just make one or two new suites, which is not that much more work. In my experience the transition away from MD-5, SHA-1 and RSA has been mostly about the ability to do SW update of deployed systems. If you’ve got data at rest secured with broken algorithms you’re gonna have to do a major data conversion operation. If you’ve got HW acceleration or HW enclaves, you’ll have to replace devices in the field. All these make the choice here look a bit insignificant to me, so I’m not too worried about it going one way or the other here. I don’t know much about PQ yet. Maybe something is different there? LL > On Mar 26, 2023, at 7:33 AM, Orie Steele <[email protected]> wrote: > > Friends, > > Recently I have had a lot of conversations regarding cryptographic agility. > > My goal in sending this message to the list is to attempt to gather what > consensus may exist within IETF on the subject. > > The topic is difficult, because many people think certain forms of agility > are "good" and others are "bad"... > and the answers are often inconsistent across subject matter experts. > > So far, I have learned of basically 2 camps. > > The "low agility, named cipher suite" camp, where primitives, parameters and > algorithm are all combined into a named algorithm, such as ES256, which uses > ECDSA on secp256r1 with sha256, or ECDH-ES+A256KW, which internalizes a KDF > > The "high agility, parameterized algorithm" camp, where the algorithm is > fixed, but all its parameters and primitives are exposed, typically in > registries dedicated to the "fixed algorithm", they are not meant to be "used > with other algorithms". HPKE is an example of this, kem, kdf, aead, each are > bound to "HPKE", they are not meant to be used by other algorithms, and > unlike ES256, ECDH-ES+A256KW, HPKE is only a meaningful name when these > parameters are supplied along with it. > > Because time is a factor in all cryptography and standards work, it is easy > to generalize these 2 camps as "the old way" and "the new way"... but I > wonder if that is wise to do, or if there is something special about HPKE or > encryption that implies "the new way" is not meant to be taken for other "new > work", such as digital signatures. > > It is worth noting that if the KDF or hash function is broken and you picked > "the old way"... you might end up needing to do a lot more work than simply > moving to a new registry entry for KDF or hash function... During that time, > bad stuff could be happening in all the places where the broken cipher suite > was deployed... You might also be forced to do this work because of the > regular lifetime of cryptographic primitives... This could be interpreted as > a "higher maintenance" cost for "the old way", you are forced to throw out > the whole car, because 1 part is no longer safe to use. > > The main motivation for this question comes from work I have collaborated on > regarding post quantum key and signature representations for JOSE and COSE. > > - https://datatracker.ietf.org/doc/draft-ietf-cose-dilithium/ > <https://datatracker.ietf.org/doc/draft-ietf-cose-dilithium/> > - https://datatracker.ietf.org/doc/draft-ietf-cose-falcon/ > <https://datatracker.ietf.org/doc/draft-ietf-cose-falcon/> > - https://datatracker.ietf.org/doc/draft-ietf-cose-sphincs-plus/ > <https://datatracker.ietf.org/doc/draft-ietf-cose-sphincs-plus/> > > I also explored applying the same approach to kyber: > > - https://datatracker.ietf.org/doc/draft-steele-cose-kyber/ > <https://datatracker.ietf.org/doc/draft-steele-cose-kyber/> > > ^ these are all in the style of "the old way"... they try to make use of > "alg" and internalize parameters and primitives into a single useful name, > for example "CRYDI5" uses dilithiums's parameter set 5, "SPHINCS+256f" uses > sphincs's parameter set 256f. > > Perhaps an example of "the new way", can be found in: > > - https://datatracker.ietf.org/doc/draft-ajitomi-cose-cose-key-jwk-hpke-kem/ > <https://datatracker.ietf.org/doc/draft-ajitomi-cose-cose-key-jwk-hpke-kem/> > > In section 4.1, the kty is "HPKE-KEM", but this is meaningless without "hkc", > which is the key configuration, which defines the parameters that are allowed > for the key, a single kem id, and an array of kdf and aead identifiers. > > It is a bit awkward to compare key design for kems and digital signatures, > and yet, I think developers will hope for some consistency in the post > quantum key representations, even if there are no examples like P256 that is > used for both ECDSA and ECDH-ES. > > Just for the sake of argument, let us imagine an HPKE inspired Dilithium key > with hash before sign (a made up additional agility parameter): > > { > kty: "HPKS", // similar to HPKE, useless without parameters / configuration > hkc: { // like HPKE Key Configuration, but for "Hybrid Public Key Signature > Key Configuration" > parameter_set: CRYSTALS-Dilithium parameter set 5 // like kem id, bound > to pub / priv. ... REQUIRED > digests: [ shake256, sha256 ] // like kdfs, aeads not bound to pub / priv > ... OPTIONAL > // are there other parameters that are internalized in "the old way", > that you can think of that would go here? > } > pub: ..., // public key, but more obvious than x > priv: ... // private key, but more obvious than d > } > > Similar to EdDSA with Ed25519, it would be annoying to use sha256 here, since > dilithium uses shake256 internally, (EdDSA uses sha512 internally). > > Do we need to make something like HPKE, but for keys for signatures, > something like HPKS? > > What happens to the old registry entries and old key formats if we fully > embrace "the new way"? > > Should post quantum keys use "the old way" or "the new way" or "both / it > depends" ? > > As an author on the post quantum signatures work, what else should I be doing > to make sure the drafts reflect the "best path forward"? > > Regards, > > OS > > -- > ORIE STEELE > Chief Technical Officer > www.transmute.industries > > <https://www.transmute.industries/> > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
