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

[Göran Selander <[e-mail]>]

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" <[e-mail]> wrote:

    Hi all,

    A recent feature request for openssl
    (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
    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://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
    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