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

Benjamin Kaduk <kaduk@mit.edu> Tue, 12 January 2021 19:19 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4DD3A1068; Tue, 12 Jan 2021 11:19:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UR2an5Fcq8pa; Tue, 12 Jan 2021 11:19:18 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D39B3A1060; Tue, 12 Jan 2021 11:19:17 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 10CJJCTl017760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Jan 2021 14:19:16 -0500
Date: Tue, 12 Jan 2021 11:19:11 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: draft-ietf-core-oscore-groupcomm@ietf.org
Cc: core@ietf.org
Message-ID: <20210112191911.GT161@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/ujj_I-LlqW9fq__quh-YqKS0fF0>
Subject: [core] Concerns with EC key joint signature and DH usage in draft-ietf-core-oscore-groupcomm
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jan 2021 19:19:20 -0000

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