Re: [icnrg] Vessel Container Format

Jens Finkhaeuser <jens@interpeer.io> Thu, 10 November 2022 09:14 UTC

Return-Path: <jens@interpeer.io>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2B9C1522BA for <icnrg@ietfa.amsl.com>; Thu, 10 Nov 2022 01:14:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 (1024-bit key) header.d=interpeer.io
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 cYeRhVRdZ5ov for <icnrg@ietfa.amsl.com>; Thu, 10 Nov 2022 01:14:16 -0800 (PST)
Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5DDC14CE38 for <icnrg@irtf.org>; Thu, 10 Nov 2022 01:14:15 -0800 (PST)
Date: Thu, 10 Nov 2022 09:14:02 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interpeer.io; s=protonmail; t=1668071652; x=1668330852; bh=j3zg4GMYsUA+Hf1H//uyhcacgzsbCldIE5L8KC8/SIs=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=bHSrlJgRUIFTYZxVhW3chsaBYphwgbjE2cshwjTcUcZj7cJ9DZavY5YP2++7TwLH0 P2x8q+EkGIlciCKaAculweX85wv/K1kq9fzz7RWoWfCuoXzdVlgmQCtPBj6de8Zlv1 BwwPnH5I3Y7sdfaxZwX6xfehSRn/gdrsL9LXSdls=
To: ICNRG <icnrg@irtf.org>
From: Jens Finkhaeuser <jens@interpeer.io>
Message-ID: <-k8uPW5PEPBYD_TwxvsfIgxKhhv5DvtOiAVeef52DGc5QRzjQBAANyBXQ_CibQNHVHSEJOEyJBA0LSBusP9y6jS0xc-uCVQZrTqCEyz5H-0=@interpeer.io>
Feedback-ID: 18725731:user:proton
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha512"; boundary="------03872f89b896a7d00c050438a57323a53484869aaf692cf5cfbe7c772558b422"; charset="utf-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/6K-yk2f4ouzQwXPux00Psb3aXDs>
Subject: Re: [icnrg] Vessel Container Format
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Nov 2022 09:14:21 -0000

Hi,

after my presentation on Tuesday, one question was raised that I feel I did not respond to satisfactorily, which I would like to address now: why focus on deletion so much?

There are two answers.

1.  It's the law. I am not a lawyer, of course, so the actual legal interpretation of such things remains to be seen. But I would doubt that when faced with someone legally requesting the deletion of PII, a judge would look kindly upon an answer that is effectively "I forgot I have it". The exact measure of "reasonable effort" is not up to me, but I think a slightly better answer than that is going to be required if such a thing is tested (I recall similar arguments surrounding the notion of legally copying IP-protected data).
2.  Relying on cryptography assumes everything working well, until the cryptographic solution fails, at which point all bets are off. But there are plenty on scenarios that are not that binary. Specifically, it is not guaranteed that a malicious party that comes into possession of a compromised key does so after already having received encrypted content blocks. In such a scenario, of course, deletion does nothing.
    But in a more opportunistic scenario where the malicious party requests content only as a result of having acquired a key, deletion can protect against leaking of sensitive data. Such mitigation also relies on a specific sequence of events (deletion to occur before requesting), but this sequence is far from improbable.


In summary, I consider it somewhat negligent not to include deletion as a first class problem into ICN solutions, but YMMV of course.

At any rate, thank you very much for this feedback! At minimum, it's become clear that I need to stress these points in the draft.

Jens