Subject: [COSE] IANA COSE assignments

From: Göran Selander <[email-masked]>
Date: Thu, 28 Jan 2021 09:17:56 +0000

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:
 
 ”The math used to obtain the computed secret is based on the curve selected and not on the ECDH algorithm.  For this reason, a new algorithm does not need to be defined for each of the curves.”

As another example, ECDSA is bundled with a hash function (see table 1) but not  with the elliptic curve, see Section 2.1:

”This document defines ECDSA to work only with the curves P-256,
P-384, and P-521. Future documents may define
it to work with other curves and points in the future.”

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

It isn't clear to me when to follow the guidance in [1] and when to make an exception. Just because there is one exception doesn't seem like reason enough to register bespoke bundlings. 

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.

As I see it,  there should be a good reason to not assign according to the the intentions of [1], and if we deviate from those then we should preferably be able to explain according to what principle that assignment was made so that the new principle can be followed (until potentially other examples requires us to reconsider).

Any views on that?

2. Another point relates to how specifications use COSE code points. For example, [1] recommends the use of deterministic ECDSA. If that is not used, is that reason to register another ECDSA code point? Or, if the cofactor of the curve is not equal to 1, is that reason to register another ECDSA code point? In other words, to what extent is the IANA number registration bundled with certain properties for which there is no register? 

An alternative to make new assignments is that the referencing document re-uses existing code points and specifies how they are used, including why and how deviations are made from the math or the recommendations. 

Opinions?

3. ECDH-EE is not specified in [1], whereas ECDH-ES and ECDH-SS are carefully distinguished in the registries. I would be hesitant to register ECDH-EE algorithms without any supporting specification describing how it is expected to be used in general. What does the WG think?

Chairs: Unless sorted out before, could we have some time at the next interim?

Thanks
Göran

[1] https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-algs-12

---

From: Michael Richardson <[email-masked]>
Date: Thu, 28 Jan 2021 08:49:21 -0500

Göran Selander wrote:
    > It isn't clear to me when to follow the guidance in [1] and when to
    > make an exception. Just because there is one exception doesn't seem
    > like reason enough to register bespoke bundlings.

Perhaps the WG needs to better understand the request in order to think about
whether or not you should grant an exception.
I guess that the request includes a bundling of things.
Perhaps the requestor just believes that they must do that, but didn't intend
to create an exception?

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

Agreed.

    > 2. Another point relates to how specifications use COSE code
    > points. For example, [1] recommends the use of deterministic ECDSA. If
    > that is not used, is that reason to register another ECDSA code point?

Yes, but not necessarily a short one :-)

    > Or, if the cofactor of the curve is not equal to 1, is that reason to
    > register another ECDSA code point? In other words, to what extent is
    > the IANA number registration bundled with certain properties for which
    > there is no register?

    > An alternative to make new assignments is that the referencing document
    > re-uses existing code points and specifies how they are used, including
    > why and how deviations are made from the math or the recommendations.

That would seem to lead to interoperability issues, and also complexity for
those creating reuseable libraries.

    > 3. ECDH-EE is not specified in [1], whereas ECDH-ES and ECDH-SS are
    > carefully distinguished in the registries. I would be hesitant to
    > register ECDH-EE algorithms without any supporting specification
    > describing how it is expected to be used in general. What does the WG
    > think?

I think that the use case needs to be clear.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Göran Selander <[email-masked]>
Date: Thu, 28 Jan 2021 14:15:56 +0000

Thanks Michael,

Case in point: https://mailarchive.ietf.org/arch/msg/cose/3YfGTnI8fdJwl4fS_OFw2AFxXNE/

Göran

On 2021-01-28, 14:50, "Michael Richardson" <[email-masked]> wrote:

    Agreed.

---

From: Russ Housley <[email-masked]>
Date: Thu, 28 Jan 2021 12:18:09 -0500

> As I see it,  there should be a good reason to not assign according to the the intentions of [1], and if we deviate from those then we should preferably be able to explain according to what princip…

I like the principle that a new algorithm does not need to be defined for each of the curves.  That leads to a huge number of code points.  So, I think you are right that exceptions should come with a rationale,

> An alternative to make new assignments is that the referencing document re-uses existing code points and specifies how they are used, including why and how deviations are made from the math or the…

My reading of draft-ietf-cose-rfc8152bis-algs-12 is that implementations SHOULD use a deterministic version of ECDSA.  This means that other ECDSA implementations are still consistent with the use of these code points.  I think that Section 2.1.1 further supports this interpretation.

> 3. ECDH-EE is not specified in [1], whereas ECDH-ES and ECDH-SS are carefully distinguished in the registries. I would be hesitant to register ECDH-EE algorithms without any supporting specificatio…

If someone has a use case for ECDH-EE, then the should write a document to get the code point(s).

Russ

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 28 Jan 2021 19:37:03 +0200

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

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

---

From: Göran Selander <[email-masked]>
Date: Fri, 29 Jan 2021 15:01:15 +0000

Thanks Russ! 

Good feedback. Some comments inline. 

On 2021-01-28, 18:18, "Russ Housley" <[email-masked]> wrote:

[GS] OK, good. Anyone has a preference for how to document that? Perhaps it is enough to type it into the mail exchange between expert and IANA.

[GS] Right, so this is in favor of reusing the existing assignments.

[GS] Agree. That use case is potentially of general applicability and would complement draft-ietf-cose-rfc8152bis-algs so I assume that document should be reviewed by the COSE WG.

Göran

---

From: Göran Selander <[email-masked]>
Date: Fri, 29 Jan 2021 15:01:31 +0000

Thanks Ilari!

Good input, some questions inline.

On 2021-01-28, 18:37, "[email-masked] on behalf of Ilari Liusvaara" <[email-masked]> wrote:

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

[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?

[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

[GS] OK.

[GS] Right, this is what we want to avoid.

Göran

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 30 Jan 2021 14:46:25 +0200

On Fri, Jan 29, 2021 at 03:01:31PM +0000, Göran Selander wrote:
> [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.

Just to be clear, that is just for the shared secret, not the public
points.

As formulas:

output(X) = encodex(h*X)
decode(encode(X)) = X.

ka=output(a*decode(encode(b*G))=output(a*b*G)=encodex(h*a*b*G)=
encodex(h*b*a*G)=output(b*a*G)=output(b*decode(encode(a*G))=kb

Which is cofactor ECDH with output being x coordinate only. Which should
still work even if either or both sides mess up the sign (e.g., not
bothering to recover it from ladder).

> [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?

And another clarification, since SHAKE is a XOF, the output length needs
to be specified. Usual choices are 256 for SHAKE128 and 512 for
SHAKE256 (these are the minimum lengths to max out the collision
resistance).

One thing to note that different descriptions use different notation
here:

- "SEC 1: Elliptic Curve Cryptography" uses e.
- Wikipedia uses z.
- FIPS 186-4 does not have relevant parts.
- FIPS 186-5 draft uses e.
- IEEE 1363 uses f.
- I can't check what X9.62 uses (paywall).
- RFC6090 uses h(M)

... So might want to use "e" instead of "z".

And what happens here follows from the following rules:

1) Take first up to ceil(log2(n)) bits of hash (n is the order of the
   curve basepoint). This is by ECDSA specification.
2) If one needs to take partial octet, take the least significant bits.
   The bit order is by SHA-3 specification.
3) The (partial) octets are decoded as big-endian integer. Not taken
   bits do not contribute. This is by ECDSA specification.

(If SHA-2 was used instead, the rule #2 would say most signficant bits
instead, by SHA-2 specification. If one takes a look at SHA-3/SHAKE
software implementation, one sees everything is little-endian and
lanes are reversed, as this is a handy trick to not have to bitswap
bytes (which is slow). In contrast, SHA-2 implementations are just
big-endian).

As example, W448 with SHAKE256 (512 bits).

1) Take first 446 bits of hash. This is 55 complete octets (indexes
   0 to 54 inclusive), and 6 leftover bits.
2) The 6 leftover bits come from 6 least significant bits of 56th
   octet (index 55).
3) The 56 groups, first 55 being full 8 bits and the last one being
   only six are decoded as big-endian integer. Due to the two missing
   bits, the 55th octet (index 54) is 64s.

As to why this does not come up with P-256 (secp256k1) and P-384:
ceil(log2(n)) is multiple of 8, and hash length is multiple of 8,
so one never ends up taking a partial octet.

And for P-521 the reason is different. ceil(log2(n)) is so big (521)
that all bits of hash end up being taken.

I also took a look at libnettle source to discover how it handles
this. It takes the message to sign as hash value, with no reference
to hash function used and uses the following algorithm:

1) Decode the full hash as big-endian integer.
2) If ceil(log2(n)) is greater than hash length, shift right by the
   difference.

... Which would take the most significant bits of any partial octet
(like for SHA-2).

> [GS] Do I understand right that you think we should have used
> algorithm -7 and curve 8 instead of algorithm -47 only?
> 

Right.

-Ilari

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 31 Jan 2021 12:56:01 -0800

Hi Göran,

I'm replying late to the thread, so I can refer to all the good discussion
that's happened already :)

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

I agree with other commenters that ES256K should be considered to be an
exception/historical accident.  A reading of RFC 8812 suggests that perhaps
the new signature codepoint was not as much about using the curve for
signatures but rather about not using the curve for anything else.  This
note from 8812 also seems to come into play:

   Care should be taken that a secp256k1 key is not mistaken for a P-256
   [RFC7518] key, given that their representations are the same except
   for the "crv" value.  As described in Section 8.1.1 of [RFC8152], we
   currently do not have any way to deal with this attack except to
   restrict the set of curves that can be used.

> As I see it,  there should be a good reason to not assign according to the the intentions of [1], and if we deviate from those then we should preferably be able to explain according to what princip…

Another +1 from me on needing to be able to justify the exception.

> 2. Another point relates to how specifications use COSE code points. For example, [1] recommends the use of deterministic ECDSA. If that is not used, is that reason to register another ECDSA code p…

For deterministic vs. nondeterministic ECDSA, I think it is clear that the
codepoint allows both.  For the cofactor, it is not quite so clear-cut:
Ilari's proposal seems sound and ought to work, but it may end up requiring
us to rely on implementors reading the details carefully in order to get
correct operation.  I could imagine defining a new codepoint for "ECDSA
with non-unity curve cofactor" to call this out, though that is just a
brainstorming note and I am not saying (at this time) that I would prefer
to do that over Ilari's proposal.

> 3. ECDH-EE is not specified in [1], whereas ECDH-ES and ECDH-SS are carefully distinguished in the registries. I would be hesitant to register ECDH-EE algorithms without any supporting specificatio…

I have some vague recollection that ECDH-EE was challenging due to the lack
of a stable key identifier to use.  But I'm not even sure how I would go
about turning that vague recollection into something concrete from the
mailing list/meeting archives.

Thanks for bringing all of this to the WG,

Ben