Thanks Ilari! Good input, some questions inline.
On 2021-01-28, 18:37, "[email protected] on behalf of Ilari Liusvaara" <[email protected]> wrote: On Thu, Jan 28, 2021 at 09:17:56AM +0000, Göran Selander wrote: > > Hi all, > > I'm one of the designated experts for the IANA registry of COSE > algorithms and I need some guidance from the WG. > > 1. Current IANA assignments and instructions for COSE algorithms [1] > intentionally bundles certain parameters whereas others are not > bundled. > > For example, all COSE registrations of ECDH include key derivation, > but ECDH algorithm and elliptic curve are not bundled. Section 6.3.1. > states: Here, things get bit more complicated with Wei25519/Wei448. These curves have h!=1 (unlike every past elliptic curve in COSE, which all have h=1), so it makes sense to multiply at the end by h in order to guard for attacks with small subgroups ("co-factor ECDH"). However, RFC8152 defers to RFC6090 for ECDH, and RFC6090 assumes that h=1. However, RFC8152 also species the output encoding per curve, so one could specify special output encoding that multiplies by h before encoding in order to take h into account. This should give co-factor ECDH on the new curves without defining any new algorithms. [GS] This sounds a good way forward. Anyone has a preference for how to document that? That output encoding supporting h!=1 cofactor is potentially of general applicability and would complement draft-ietf-cose-rfc8152bis-algs so I assume it should be reviewed by the COSE WG. > As another example, ECDSA is bundled with a hash function (see table > 1) but not with the elliptic curve, see Section 2.1: This is the way ECDSA is traditionally done in specifications. For ease of correct implementation, one wants as little information associated with the message (ideally none) that can contradict the information in the key. JOSE is well-known for vulnerabilities arising from implementations using information from message over information from the key. And then some folks misdiagnosed this as problem with algorithm agility. The most well-known protocol to not do things the traditional way is TLS 1.3. However, I think this is in order to simplify negotiation, which is not appliciable to COSE. It definitely does not make implementations easier (many implementations probably do not check proper curve matching, which fortunately does not cause security issues). The new curves might be paired with SHAKE128 or SHAKE256, but those could be handled (modulo a nasty implenentation trap) by defining ECDSA with SHAKE128 and ECDSA with SHAKE256 algorithms. As to what that nasty implementation trap is: With the new curves, how the hash is converted into input z is different for SHA-2 and SHA-3 (including SHAKE). With traditional curves, that conversion is the same for SHA-2 and SHA-3. [GS] OK, so in that case we may add two more (ECDSA +hash) code points, which could then be used with other curves. But that would require a description of the different input z. Can that input be generally described for a large range of curves or is there a need to change this specification whenever a new curve is defined? > But then there are exceptions, like ES256K [2] which bundles > signature algorithm, hash function and elliptic curve. I view that a past mistake. [GS] Do I understand right that you think we should have used algorithm -7 and curve 8 instead of algorithm -47 only? ES256 -7 ECDSA w/ SHA-256 secp256k1 8 EC2 SECG secp256k1 curve ES256K -47 ECDSA using secp256k1 curve and SHA-256 > There are different principles in action here. Security is one, where > a bundling is made to ensure suitable combinations. Structure and > economy of code points seems to be another, where it may become an > issue managing the numbers if every potential bundling of parameters > can get a unique assignment. In my view "strength matching" is mostly about performance. How to get maximum security for given budget, not that strengths of all components are the same. Which is not well-defined anyway due to different sub-treshold scaling (model affects the security level). E.g., NIST P-384 is significantly stronger than AES-192. [GS] OK. With "256-bit level" cryptography, this does not matter much as security levels are so stratospheric that few dozen bits here or there matters very little. Another part is broken combinatorial explosion of combinations. The most well-known example of this are ciphersuites in TLS 1.2, and that is a nightmare to implement properly (most implementations probably fail). [GS] Right, this is what we want to avoid. Göran _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
