[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