Subject: [core] Concerns with EC key joint signature and DH usage in draft-ietf-core-oscore-groupcomm

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 12 Jan 2021 11:19:11 -0800

Hi all,

A recent feature request for openssl
(https://github.com/openssl/openssl/issues/13630) pointed out that this
document rather blithely proposes to reuse signature (e.g., EdDSA and
ECDSA) keys for purposes of ECDH key agreement.  (This is part of the
"pairwise keys" construction in Section 2.3, specifically in 2.3.1.)

Use of a given key with multiple algorithms diverges from general
cryptographic best practice, and I do see that this draft acknowledges
this fact and attempts to justify the choice in the security
considerations (Section 10.12) with reference to [Degabriele]
(https://eprint.iacr.org/2011/615).  However, I do not think that the
current discussion (in the -10) is anywhere close to sufficient
justification that the proposed behavior is secure.  Specifically, the
referenced paper primarily focuses on methods used for EMV standards,
and in particular limits itself to ECIES (which combines key agreement
and message encryption).  While OSCORE provides mechanisms conceptually
similar to ECIES, the actual mechanics of the cryptography and wire
protocol are, to my knowledge, different, and so the referenced paper
does not seem to directly apply.  This document does not attempt to
"bridge the gap" between what it does in practice and the
(ECIES-specific) proof, so based on my current understanding, it must
still be considered as defying best current practice without formal
cryptographic justification.

In my opinion, we need to either produce a reference/proof that does
apply to OSCORE's usage, or remove this mechanism from the protocol.

-Ben

---

From: Göran Selander <[email-masked]>
Date: Wed, 20 Jan 2021 14:05:45 +0000

Hi Ben,

Thanks for bringing up this already in the WG. 

Below we recap the reasoning which led to use the same public key in pairwise mode as in group mode. Triggered by your mail we revisited the problem area and we agree that simply referring to [1] as is currently done is not sufficient motivation. More details further below.

1. [1] does prove the joint security of a DH-based KEM and signing using ECDSA or elliptic curve Schnorr signatures. The KEM is then used in ECIES, but that does not limit the proof to this setting, and the use of static DH in the protocol can be mapped to a KEM setting. 

2. We made an assessment similar as for Signal's X3DH [2] which uses the same XEdDSA [3] key pair for DH and signing (the conversion between Edwards and Montgomery coordinates in that case is in the reverse direction).

3. The pairwise mode as specified in the draft works with separate signature and key agreement keys, but that would incur double overhead both in terms of key distribution and storage. The construction in [1] is a desirable optimization that has an impact on performance in constrained settings.

4. One major reason why to not use one key with multiple algorithms is because there may be vastly different policies associated with the different uses. That is not the case here, where the purpose of both uses is to protect the communication between endpoints during the validity of the group context.

With this we found it motivated to re-use the signature key of group mode as key agreement key of the pairwise mode. But the setting is not identical to the literature so a further motivation is needed. We have opened an issue on the CoRE WG github. Allow us to get back with more details. 

Göran

[1] https://eprint.iacr.org/2011/615.pdf
[2] https://signal.org/docs/specifications/x3dh/
[3] https://signal.org/docs/specifications/xeddsa/

On 2021-01-12, 20:19, "Benjamin Kaduk" <[email-masked]> wrote:

    Hi all,

    (https://protect2.fireeye.com/v1/url?k=e4a3a920-bb389025-e4a3e9bb-86959e472243-27bb378ffbf586b9&q=1&e=2faf5050-4a0e-4176-8761-8cc2752fdfe1&u=https%3A%2F%2Fgithub.com%2Fopenssl%2Fopenssl%2Fissues%2F13630) pointed out that this

    (https://protect2.fireeye.com/v1/url?k=f72d4ea3-a8b677a6-f72d0e38-86959e472243-ea870c7babbcb38c&q=1&e=2faf5050-4a0e-4176-8761-8cc2752fdfe1&u=https%3A%2F%2Feprint.iacr.org%2F2011%2F615).  However, I do not think that the

    -Ben