Subject: Re: [COSE] FIDO/WebAuthn redefined the COSE EdDSA (-8) algorithm

From: Mike Jones <[email-masked]>
Date: Wed, 23 Jun 2021 16:42:10 +0000

[Writing as an individual - not a chair]

The WebAuthn and FIDO2 working group members had thought that the COSE algorithm semantics were the same as those for JOSE, where algorithm identifiers are not polymorphic.  They were wrong, but that's water under the bridge now.  The FIDO/WebAuthn usage of the algorithm identifiers requires that the identifiers used unambiguously specify all algorithm parameters.  (Note that FIDO/WebAuthn does not use COSE signatures - only COSE algorithm identifiers.)  They have done what they needed to do to remove the ambiguities arising in practice from use of polymorphic algorithm identifiers for their use cases.

Note that by the time that we registered the ES256K algorithm for signing with the secp256k1 curve in RFC 8812, we were aware of the problem and intentionally made ES256K non-polymorphic - both for JOSE and for COSE.

I believe that we should create a policy requiring that all future algorithm registrations should be non-polymorphic.  Furthermore, I believe we should consider defining and registering new non-polymorphic algorithm identifiers so that use of the existing polymorphic algorithm identifiers can be avoided and deprecated.

				-- Mike

-----Original Message-----
From: COSE <[email-masked]> On Behalf Of Ilari Liusvaara
Sent: Saturday, June 19, 2021 4:19 AM
To: Anders Rundgren <[email-masked]>
Cc: [email-masked]
Subject: Re: [COSE] FIDO/WebAuthn redefined the COSE EdDSA (-8) algorithm

On Sat, Jun 05, 2021 at 10:46:49AM +0200, Anders Rundgren wrote:
> On 2021-06-05 9:49, Ilari Liusvaara wrote:
> > On Sat, Jun 05, 2021 at 08:17:48AM +0200, Anders Rundgren wrote:
> > > F.Y.I.
> > > When a key is to be generated, the FIDO/WebAuthn "create" API 
> > > provides a list of COSE signature algorithms.  To save some bytes 
> > > they overloaded EdDSA so that it would mean EdDSA with an Ed25519 key.
> > > Seen in retrospect this was obviously a mistake since this doesn't 
> > > extend to Ed448.
> > > 
> > > However, I believe the mistake was really making EdDSA a signature 
> > > algorithm.  The "family" concept fits squarely with most 
> > > cryptographic APIs that typically only deals with specific 
> > > algorithms.
> > 
> > IMO, the mistake is using signature algorithm to specify a key type.
> > That is not just wrong for EdDSA, it is also wrong for ECDSA (e.g,
> > ES512 does not have unique key type).
> > 
> > The key create command should take the algorithm of the key as 
> > parameter, and the sole cryptogrphic algorithm it is intended for, 
> > in case there are multiple possibilities (using the same key with 
> > multiple algorithms is not cryptographically kosher).
> > 
> > Almost every signature framework I have ever seen contains the 
> > mistake that the framework lets message and key contradict each 
> > other. Usually the specification says something like "MUST check", 
> > but in practice this is a major source of security issues. Then some 
> > folks have weaponized these issues to fuel anti-algorithm-agility 
> > agenda. For COSE, I spot 6 classes (RSA, ECDSA, ECDSA with bitcoin 
> > curve, Ed25519/Ed448, HSS-LMS and WalnutDSA) of incompatible non-overlapped signature algorithms.
> > 
> > In one of my projects, I had case of flawed signature key create 
> > command (it was not this, but some other interface flaw). I ended up 
> > creating another key create command with saner semantics.
> 
> Leaving broken cryptographic frameworks aside, how about a "historical 
> compromise" where EdDSA without any specific key information would 
> default to Ed25519 keys?
> 
> In the same vein the currently unassigned -9 could do the same for
> Ed448 just to keep the symmetry :)

Is my understanding correct that FIDO/WebAuthn create key API takes in COSE _algorithm_ number and uses it to decide type of key to create?

If so, FIDO/WebAuthn create key API is just plain flawed. I do not think it is good idea to try "fix" that in COSE, especially given that the changes seem to increase risk of error in other contexts.

One really nasty hack that would not cause too much security trouble would be to reserve algid -9 so that FIDO/WebAuthn create key API interprets any request with algid=-9 as request to create Ed448 key that is to be used with EdDSA(algid=-8). But nothing else recognizes that as anything valid. In practicular, a message with algid -9 gets rejected as unknown signature algorithm (even if key is Ed448).

> The revised identifiers could for example be called something like 
> EdDSA[Ed25519] and EdDSA[Ed448] respectively.
> 
> This is indeed a bit ugly but it
> - doesn't break existing code
> - follows (albeit in a reversed fashion) your ideas about key-driven
>   signature algorithms.

IMO: Reversing key-driven signature algorithms is VERY bad idea. The whole purpose is to force implementation do needed checks, instead of allowing implementation to skip them and that being a potential security problem.

I have coded signature validation, and found that I need to plub in the type of key. Extra code yes, but if I did not have to do that, I might have forgotten to check the key type, possibly resulting in an security issue.

And for not breaking existing code, all EdDSA signatures must use the
-8 algid, so the Ed448 algid can not appear in any message.

> The only viable alternative (AFAICT...), is either stalling progress 
> by forcing API upgrades, or continued "misuse" of existing standards.
> It is a bit like choosing between pest or cholera :)

If my understanding of the issue is correct, the API should be deprecated and replaced by new one.

-Ilari

_______________________________________________
COSE mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cose

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 23 Jun 2021 18:45:39 +0200

> I believe that we should create a policy requiring that all future algorithm registrations should be non-polymorphic.  Furthermore, I believe we should consider defining and registering new non-pol…

+1

Anders

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 23 Jun 2021 12:01:57 -0700

> On Jun 23, 2021, at 9:42 AM, Mike Jones <Michael.Jones=[email-masked]> wrote:
> 

This seems good to me.

Going a bit further, the binding to a particular hash function seems important too. Aside from the security reasons, it makes means that an algorithm ID always selects a function that takes an arbitrary number of unstructured bytes to be signed/verified which makes implementation of crypto APIs cleaner and reduces code size.

It also seems more convenient in protocols like FIDO. You only need to carry a single integer around. My recollection of ASN.1 is that the structure of an algorithm specifier varies by algorithm which makes writing code for it more complex. You have to decode a structure that specifies a hash rather than just switch on an integer.

LL

---

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Jun 2021 16:10:33 -0400

Mike Jones <Michael.Jones=[email-masked]> wrote:
    > The WebAuthn and FIDO2 working group members had thought that the COSE
    > algorithm semantics were the same as those for JOSE, where algorithm
    > identifiers are not polymorphic.  They were wrong, but that's water
    > under the bridge now.  The FIDO/WebAuthn usage of the algorithm
    > identifiers requires that the identifiers used unambiguously specify
    > all algorithm parameters.  (Note that FIDO/WebAuthn does not use COSE
    > signatures - only COSE algorithm identifiers.)  They have done what

It seems like maybe this is the origin of the problem?
Since they only use the identifiers, maybe it's really just WebAuthn's problem?

    > Note that by the time that we registered the ES256K algorithm for
    > signing with the secp256k1 curve in RFC 8812, we were aware of the
    > problem and intentionally made ES256K non-polymorphic - both for JOSE
    > and for COSE.

okay.

    > I believe that we should create a policy requiring that all future
    > algorithm registrations should be non-polymorphic.  Furthermore, I
    > believe we should consider defining and registering new non-polymorphic
    > algorithm identifiers so that use of the existing polymorphic algorithm
    > identifiers can be avoided and deprecated.

I don't feel strongly here.
If going that way would surprise fewer people, then okay.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: John Mattsson <[email-masked]>
Date: Wed, 23 Jun 2021 20:59:54 +0000

Except helping FIDO/WebAuthn, what concrete benefits do you want to achieve by duplicating the public key parameters in the signature algorithm?

> Furthermore, I

That seems a bit extreme unless it has _very_ strong benefits also for non-FIDO use cases.

Maybe the solution is to create a new parallel registry for FIDO/WebAuthn.

FYI, the same topic was discussed in January:
https://mailarchive.ietf.org/arch/msg/cose/4PIPilQY8a985StsFeft0No0-YI/

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

I view that a past mistake.

From: COSE <[email-masked]> on behalf of Michael Richardson <[email-masked]>
Date: Wednesday, 23 June 2021 at 22:10
To: Mike Jones <Michael.Jones=[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [COSE] FIDO/WebAuthn redefined the COSE EdDSA (-8) algorithm

okay.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  https://protect2.fireeye.com/v1/url?k=98cb4a21-c7507324-98cb0aba-86d2114eab2f-45986f7a09c7f771&q=1&e=a8ba51b3-e454-4bba-8745-ba9b3ea383f0&u=http%3A%2F%2Fwww.sandelman.ca%2F        |   ruby on rails    [

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 24 Jun 2021 03:30:10 +0200

> Except helping FIDO/WebAuthn, what concrete benefits do you want to achieve by duplicating the public key parameters in the signature algorithm?

One very obvious problem is that cryptographic APIs do not understand what "EdDSA" is.

If you look into Jim's reference code for COSE it becomes clear that polymorphic algorithms introduce considerable fuzz.

In PKIX Ed25519 was dealt with as a concrete signature algorithm.

Anders

> That seems a bit extreme unless it has _/very/_ strong benefits also for non-FIDO use cases.
> 
> https://mailarchive.ietf.org/arch/msg/cose/4PIPilQY8a985StsFeft0No0-YI/ <https://mailarchive.ietf.org/arch/msg/cose/4PIPilQY8a985StsFeft0No0-YI/>
> 
> *From: *COSE <[email-masked]> on behalf of Michael Richardson <[email-masked]>
> *Date: *Wednesday, 23 June 2021 at 22:10
> *To: *Mike Jones <Michael.Jones=[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
> *Subject: *Re: [COSE] FIDO/WebAuthn redefined the COSE EdDSA (-8) algorithm
> 
> 
>      > The WebAuthn and FIDO2 working group members had thought that the COSE
>      > algorithm semantics were the same as those for JOSE, where algorithm
>      > identifiers are not polymorphic.  They were wrong, but that's water
>      > under the bridge now.  The FIDO/WebAuthn usage of the algorithm
>      > identifiers requires that the identifiers used unambiguously specify
>      > all algorithm parameters.  (Note that FIDO/WebAuthn does not use COSE
>      > signatures - only COSE algorithm identifiers.)  They have done what
> 
>      > Note that by the time that we registered the ES256K algorithm for
>      > signing with the secp256k1 curve in RFC 8812, we were aware of the
>      > problem and intentionally made ES256K non-polymorphic - both for JOSE
>      > and for COSE.
> 
> okay.
> 
>      > I believe that we should create a policy requiring that all future
>      > algorithm registrations should be non-polymorphic.  Furthermore, I
>      > believe we should consider defining and registering new non-polymorphic
>      > algorithm identifiers so that use of the existing polymorphic algorithm
>      > identifiers can be avoided and deprecated.
> 
> ]     [email-masked] https://protect2.fireeye.com/v1/url?k=98cb4a21-c7507324-98cb0aba-86d2114eab2f-45986f7a09c7f771&q=1&e=a8ba51b3-e454-4bba-8745-ba9b3ea383f0&u=http%3A%2F%2Fwww.sandelman.ca%2F <https://protect2.fireeye.com/v1/url?k=98cb4a21-c7507324-98cb0aba-86d2114eab2f-45986f7a09c7f771&q=1&e=a8ba51b3-e454-4bba-8745-ba9b3ea383f0&u=http%3A%2F%2Fwww.sandelman.ca%2F>        |   ruby on rails    [
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 24 Jun 2021 05:32:30 +0200

> I believe that we should create a policy requiring that all future algorithm registrations should be non-polymorphic.  Furthermore, I believe we should consider defining and registering new non-pol…

While I can’t see anything wrong with registering “ciphersuite” style algorithm identifiers like ES256k, there also is nothing wrong with “pure” algorithm identifiers.
They just can’t be used with protocols that expect the full ciphersuite to be specified in one number.
So I don’t see a reason to deprecate pure (parameter agnostic) algorithm identifiers, but we may want to complement them with a couple of ciphersuite identifiers each.

It would be useful if the registry had more data about what a specific algorithm identifier actually is (e.g., if it can be used in WebAuthn).
I think we’ll need to do a cleanup of the registry with respect to such descriptive columns, soon (compare the hash algorithms issue).

Grüße, Carsten

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 24 Jun 2021 07:01:59 +0200

> While I can’t see anything wrong with registering “ciphersuite” style algorithm identifiers like ES256k, there also is nothing wrong with “pure” algorithm identifiers.

"Wrong" may not be the right word here but having multiple strategies in frameworks like JOSE and COSE adds confusion.

For CSF (CBOR Signature Format), I followed the path provided by EC and RSA and thus redefined -8 to mean Ed25519 (like FIDO) and -9 (currently unreserved) to mean Ed448.  This enables a fully table-driven system.

Jim's reference code highlights the problem, you apparently need a custom provider in order to use Ed25519:
https://github.com/cose-wg/COSE-JAVA/blob/master/src/main/java/COSE/SignCommon.java#L32

Anders

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 23 Jun 2021 22:02:46 -0700

> On Jun 23, 2021, at 8:32 PM, Carsten Bormann <[email-masked]> wrote:
> 

They also won’t work with APIs that expects a ciphersuite to be specified. For example, an API that take an integer that is a COSE algorithm identifier and a byte buffer or byte stream of some sort that is the actual data to be signed.

LL

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 24 Jun 2021 08:28:57 +0200

> For CSF (CBOR Signature Format), I followed the path provided by EC and RSA and thus redefined -8 to mean Ed25519 (like FIDO) and -9 (currently unreserved) to mean Ed448.  This enables a fully tabl…

That is not how it works.
-9 will soon be assigned to something else.
-8 really means EdDSA, and nothing more specific.

If you need algorithm identifiers for your project that mean something specific, why don’t you go register them?
It’s not that hard (“Specification required”, but that can be a GitHub repo).

Grüße, Carsten