[ippm] draft-ietf-ippm-ioam-data-integrity
Justin Iurman <justin.iurman@uliege.be> Wed, 31 May 2023 14:33 UTC
Return-Path: <justin.iurman@uliege.be>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858E9C151078; Wed, 31 May 2023 07:33:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.394
X-Spam-Level:
X-Spam-Status: No, score=-4.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uliege.be
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG4lQp-RlBkc; Wed, 31 May 2023 07:33:02 -0700 (PDT)
Received: from serv108.segi.ulg.ac.be (serv108.segi.ulg.ac.be [139.165.32.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC65BC14CEFA; Wed, 31 May 2023 07:32:55 -0700 (PDT)
Received: from [192.168.1.62] (125.179-65-87.adsl-dyn.isp.belgacom.be [87.65.179.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by serv108.segi.ulg.ac.be (Postfix) with ESMTPSA id 1EEF6200F48E; Wed, 31 May 2023 16:32:52 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.11.0 serv108.segi.ulg.ac.be 1EEF6200F48E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uliege.be; s=ulg20190529; t=1685543572; bh=NVxGNb0N9Skr37tdcbXcqTSgvN+y4qiTuow8iLipCZQ=; h=Date:To:Cc:From:Subject:From; b=VzSuElX4ejDAclNTQjZ7v1fSAlTUvVr38jqv8wgKoEF3bhAjdDRA+KVZXT7W2JB1y Rnhy6VMzq1dp7Ay/RCidElDIPQJbTDweCs06jPMzyBbt4MhPeZREMuhRHXAkYd2YoF DFmkZe9ANI5vzykqxS3nFXTLFTppxhYHfzJ68k9EuvGO2lIVpzsgxV3oIFu+SYM1uN bfQMkPSlovslDKRVO0Jhy151jd1lGD2PxdcKVPu6woD4bEiG5d5tVXOCCa9lBmdDs/ DL+Q4chuX9o6jZR5XZFjbr7ZRvCD6WUUWyLDO/FmN+mHUPjgKdptZjoWNMRM7V/jNt 6mpD2Fw9irjSw==
Message-ID: <bd1ed58e-0ff5-98f3-0e6b-abea7439a363@uliege.be>
Date: Wed, 31 May 2023 16:32:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
Content-Language: en-US
To: IETF IPPM WG <ippm@ietf.org>
Cc: IPPM Chairs <ippm-chairs@ietf.org>, draft-ietf-ippm-ioam-data-integrity@ietf.org
From: Justin Iurman <justin.iurman@uliege.be>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/RhLU-ScqXtdSqCYqIfYwGsgaa5Q>
Subject: [ippm] draft-ietf-ippm-ioam-data-integrity
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 May 2023 14:33:07 -0000
Hi ippm, chairs, Today, we (the authors) discussed an important section of the draft and found an issue with our asymmetric key-based signature algorithm (i.e., ECDSA p256 with SHA256). Indeed, it looks like it is way too complicated to end up with a working solution, not to say maybe even impossible for the use case. This observation is also based on the feedback received from an implementer. Very briefly, the issue comes from the signature chain. A node's signature would be over (a) the previous signature and (b) the (hashed) inserted data by the node. We *cannot* afford to hash the whole thing (which is usually the case for a signature), since we need a way to "go back" (i.e., to check the signature chain in the reverse order, with public keys). Therefore, we need the previous signature to stay outside of the hash. But if we do so, the input size (provided to the signature algorithm) would be too big. As a consequence, we don't believe there is a good solution for this. Note that, on second thought, ECDSA is not used for encryption and is "only" a signature algorithm, which might not be the perfect fit for what we want (i.e., to decrypt/retrieve data). A possibility would be to use something else (e.g., RSA), without the certainty that it would even work (and the signature size would be much bigger in that case). TL;DR What we propose here is to not over complicate things unnecessarily and have only the symmetric key-based signature algorithm defined in the draft (i.e., remove the problematic asymmetric key-based signature algorithm). After all, asymmetric algorithms are usually used to safely exchange (symmetric/shared) keys, which makes us think that it's probably not worth it. If anyone thinks otherwise, please say so. If you're a security expert and think we're wrong, please speak up. We hope for feedback from the WG. Thanks, The authors
- [ippm] draft-ietf-ippm-ioam-data-integrity Justin Iurman
- Re: [ippm] draft-ietf-ippm-ioam-data-integrity Tommy Pauly
- Re: [ippm] draft-ietf-ippm-ioam-data-integrity Justin Iurman