[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
- [core] Concerns with EC key joint signature and D… Benjamin Kaduk
- Re: [core] Concerns with EC key joint signature a… Göran Selander