Re: [COSE] IANA COSE assignments

[Ilari Liusvaara <[e-mail]>]

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.

> 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.


> But then there are exceptions, like ES256K [2] which bundles
> signature algorithm, hash function and elliptic curve. 

I view that a past mistake.

> 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.

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).



-Ilari