Subject: [COSE] draft-ietf-cose-rfc8152bis-algs and deterministic ECDSA recommendations

From: John Mattsson <[email-masked]>
Date: Tue, 16 Feb 2021 12:17:08 +0000

Hi,

I just noticed that RFC8152bis has the recommendation:

"Implementations SHOULD use a deterministic version of ECDSA such as the one defined in [RFC6979]."

I don't think this is a good recommendation for IoT devices. In the last 5 years, i.e. after work on RFC 8152 started, there has been a large amount of academic papers showing that purely deterministic ECC algorithms in accesable IoT devices suffers from side-channel and fault injection attacks. For a list of papers see e.g. Seciton 1 of https://tools.ietf.org/html/draft-mattsson-cfrg-det-sigs-with-noise-02

I would suggest changing the SHOULD to MAY, but I know the draft is already in RFC editors que...

Alternatively (or additionally) the draft could add some non-normative security consideration regarding deterministic ECC signatures.

"Deterministic elliptic-curve signatures such as deterministic ECDSA
and EdDSA have gained popularity over randomized ECDSA as their
security do not depend on a source of high-quality randomness.
Recent research has however found that implementations of these
signature algorithms may be vulnerable to certain side-channel and
fault injection attacks due to their determinism. See e.g. Section 1 of
[draft-mattsson-cfrg-det-sigs-with-noise] for a list of attack papers."

Recommending deterministic ECDSA for IoT devices without any security considerations would not be good.

FYI, CFRG has discussed and agreed that this is a problem.

Cheers,
John

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 16 Feb 2021 13:50:36 +0100

> Recommending deterministic ECDSA for IoT devices without any security considerations would not be good.

+1

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Feb 2021 12:59:01 -0500

John Mattsson <john.mattsson=[email-masked]> wrote:
    > I don't think this is a good recommendation for IoT devices. In the
    > last 5 years, i.e. after work on RFC 8152 started, there has been a
    > large amount of academic papers showing that purely deterministic ECC
    > algorithms in accesable IoT devices suffers from side-channel and fault
    > injection attacks. For a list of papers see e.g. Seciton 1 of
    > https://tools.ietf.org/html/draft-mattsson-cfrg-det-sigs-with-noise-02

    > already in RFC editors que...

I will read your ID and think about it.
In my experience, the use of randmized ECDSA has two negative effects:

1) it's really hard to judge quality of randomness when writing a library
   or module, and so even clueful application builders can miss this.

2) unit test cases wind up as non-deterministic, so either the randomized
   input is made deterministic, or the randomized version is just not tested.
   Since unit test cases often serve as documentation, which is copy&pasted,
   the result is that the randomized version is used with a constant input.

We've seen this with DSA vs RSA back 20 years ago.
I was really annoyed with ECDSA until the deterministic version came to
light, and I really don't want to go back.

    > security do not depend on a source of high-quality randomness.  Recent
    > research has however found that implementations of these signature
    > algorithms may be vulnerable to certain side-channel and fault
    > injection attacks due to their determinism. See e.g. Section 1 of

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 16 Feb 2021 22:55:41 +0100

> light, and I really don't want to go back.

For environments with questionable random number generators,
going from full reliance on that randomness to deterministic certainly was progress.
We certainly don’t want to go back on that for IoT applications.
But we can’t ignore the attacks that have become possible by deterministic processing.
So adding back in some randomness, without again fully relying on that, seems to be the way to go in the future.
That is what the security considerations could say.

Grüße, Carsten