From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id GNyXLcZp+mE83QAAgWs5BA (envelope-from ) for ; Wed, 02 Feb 2022 12:23:50 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id wDIyJsZp+mHWNgAAG6o9tA (envelope-from ) for ; Wed, 02 Feb 2022 12:23:50 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 59B722906C for ; Wed, 2 Feb 2022 12:23:50 +0100 (CET) Received: from localhost ([::1]:48230 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nFDjo-0002h0-Uw for larch@yhetil.org; Wed, 02 Feb 2022 06:23:48 -0500 Received: from eggs.gnu.org ([209.51.188.92]:35720) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nFDi9-00021q-GS for guix-patches@gnu.org; Wed, 02 Feb 2022 06:22:05 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:57752) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nFDi6-0000tw-4z for guix-patches@gnu.org; Wed, 02 Feb 2022 06:22:04 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nFDi5-00027B-S1 for guix-patches@gnu.org; Wed, 02 Feb 2022 06:22:01 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#52555] [RFC PATCH v2 0/5] Decentralized substitute distribution with ERIS Resent-From: pukkamustard Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 02 Feb 2022 11:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52555 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Maxime Devos Cc: ~pukkamustard/eris@lists.sr.ht, 52555@debbugs.gnu.org Received: via spool by 52555-submit@debbugs.gnu.org id=B52555.16438008658047 (code B ref 52555); Wed, 02 Feb 2022 11:22:01 +0000 Received: (at 52555) by debbugs.gnu.org; 2 Feb 2022 11:21:05 +0000 Received: from localhost ([127.0.0.1]:51649 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFDhB-00025j-8r for submit@debbugs.gnu.org; Wed, 02 Feb 2022 06:21:05 -0500 Received: from mout02.posteo.de ([185.67.36.66]:46045) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFDh8-00024r-5n for 52555@debbugs.gnu.org; Wed, 02 Feb 2022 06:21:04 -0500 Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 285FE240103 for <52555@debbugs.gnu.org>; Wed, 2 Feb 2022 12:20:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1643800856; bh=pNHT9Ob/g9tMWWqHoN2a1tCk6AY/iboxTEfny8CifK8=; h=From:To:Cc:Subject:Date:From; b=N9GnxVzwSKNW92Zg8Qgddb5eGbZUR1y30Js0tVxFjUUsaBBh1nNQbBh1r9ALMG4xQ sI/P0SzWhjb7IrYIFzZkrXWKc2UC8LzSQsl4VNdrrEQyKE6gjtQQihLyc9BspJccD2 ZuBQn7X9DWWnT1N6AU+z43svr1AEPSxFYjsmLxq3gekYezDIULwswVx2h293gAy9Dz XtJzVCaPQwLWBh6xhUxsISBAWb8R38Wwt0AXflRs88rlUG9VHyrLIR4DMvguyeF7aD t/Hbv4r8wgMmn07shRuQ+ZKWUCOI3DYZE//T4pxuK/FvNTjzNROmLIe7O6XeWihey8 Op04GXSyjTEog== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4JpfVv0TMSz9rxG; Wed, 2 Feb 2022 12:20:54 +0100 (CET) References: <20211216161724.547-1-pukkamustard@posteo.net> <20220125192201.7582-1-pukkamustard@posteo.net> <73b50ffdca94407ef9fd7ef4875985a3b1c3c568.camel@telenet.be> From: pukkamustard Date: Wed, 02 Feb 2022 11:10:58 +0000 In-reply-to: <73b50ffdca94407ef9fd7ef4875985a3b1c3c568.camel@telenet.be> Message-ID: <86bkzph5ux.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1643801030; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=uWG1yFdWuE7rPjrIN3qjC84//ZdVCWpl1YsM8T863G8=; b=Et6Y3TTlhb2MPt1g79KxfW4aKKwYI0E/DHLvRegxVsl1DwaGFoelOSCJJzN5x7sZA9ehrw xSzH0PgnXVghpPq3y9VN9dc4ya/Cgn3BaF9eIN/iTApvX85b8GtlMPLSrHZbhUoZhTuObT EBRRm3YUagxvYDkTe2eM9Y9LOmw2CVfCo+YU44AuvAGjXwa02htwrVtVqqGg6SyPMMZnWd o+Cth0r5H1nv8DTHZ+FSb5XehCYsu8KHmq98f9A7wzRPkw4zNfN8NGgnxQlYIm24mcqL8G dWbZpvAx3vwd6b0HJV8r807P91dTU0PrTVFS7RX9smJw8c0qdE7lihENpmm78w== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1643801030; a=rsa-sha256; cv=none; b=mRQ3HkDMP0cERfMv8qZaWx6LFSVkv/LUlQe2MCn6pC/X6nczUQEHva73k5LXBoswhJwegi RIcZNisNOPsEd72MqkdP6uD7CJO8gFt5QHPgTw/31fE6V50q9zdbZb52fBMkkLTPCeaHTt sA2ffzxhZi0RUklECRfYpWZkUOJE22V3dNZu+KVYLtH0LKcrioOtW1uL+2CXV/zWHHunbu vDtSHXR5UvS4LlSjV5sOxbBwxODqwxgx5qqGLruZr25s6ImlB8uw2+Ac4vZRIH/VrSbc29 uHqhX3uEX74VTJFHgT0NnJlaDTk4SSH4jED+p74O0cKNzDGmMS4/6nDRliVRMw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=posteo.net header.s=2017 header.b=N9GnxVzw; dmarc=fail reason="SPF not aligned (strict)" header.from=posteo.net (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -2.23 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=posteo.net header.s=2017 header.b=N9GnxVzw; dmarc=fail reason="SPF not aligned (strict)" header.from=posteo.net (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 59B722906C X-Spam-Score: -2.23 X-Migadu-Scanner: scn1.migadu.com X-TUID: rYKkEjmqWPtQ Maxime Devos writes: > [[PGP Signed Part:Undecided]] > Hi, > > Is it possible for the following situation to happen? > If so, why not? > > 1. server A is authentic > 2. server M is malicious, it tries to trick the client into > installing an incorrect substitute > 3. (key of) server A is authorised > 4. (key of) server M is _not_ authorised > 5. server A and M are both in substitute-urls > 6. server A only serves =E2=80=98classical=E2=80=99 substitutes, server= B also serves > via ERIS+ipfs > 7. Both A and M set the same FileHash, References, etc. in the > narinfo > 8. However, M set an ERIS URN pointing to a backdoored substitute. > 9. The client trusts A, and A and B have the same FileHash etc., > so the client considers the narinfo of B to be authentic > because it has the same FileHash. > 10. The client prefers ERIS above HTTP(S), so it downloads via M. > 11. The client now installed a backdoored substitute! > > Greetings, > Maxime. No this should not work. The ERIS URN is only used if the entire narinfo is signed with a authorized signature. The FileHash is not used when getting substitutes via ERIS (being able to decode ERIS content implies integrity). The interesting case that would be allowed with ERIS is following: 1. Server A is authentic and its key is authorized. 2. Servers M1 to MN are potentially malicious and their keys are not authorized. 3. Server A and servers M1 to MN are in the substitute-urls. 4. Client gets Narinfo from server A and uses the ERIS URN from there. 5. Client can get blocks simultaneously from Server A and servers M1 to MN. 6. Client decodes content with the ERIS URN and can be sure that they have the valid substitute. So client only needs to trust A but can use M1-MN (simultaneously) for fetching the content. -pukkamustard