From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 2C92394BED for ; Fri, 23 Feb 2024 10:26:41 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 16125152DF for ; Fri, 23 Feb 2024 10:26:41 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Fri, 23 Feb 2024 10:26:40 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 5774B44EB6 for ; Fri, 23 Feb 2024 10:26:40 +0100 (CET) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 23 Feb 2024 10:26:39 +0100 Message-Id: From: "Stefan Sterz" To: "Proxmox Backup Server development discussion" X-Mailer: aerc 0.17.0-57-g782a17dfb056 References: <20240215152001.269490-1-s.sterz@proxmox.com> <20240215152001.269490-13-s.sterz@proxmox.com> <736a3096-d3dc-40ca-850a-e7f85a155d7e@proxmox.com> In-Reply-To: <736a3096-d3dc-40ca-850a-e7f85a155d7e@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL -0.078 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pbs-devel] [PATCH proxmox-backup 12/12] auth: us ec keys as auth keys X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2024 09:26:41 -0000 On Mon Feb 19, 2024 at 8:10 PM CET, Max Carrara wrote: > On 2/15/24 16:20, Stefan Sterz wrote: > > this commit moves new installations from our default rsa keys toward > > smaller and more efficient ec keys. this uses the `PrivateKey` and > > `PublicKey` structs from proxmox-auth-api to handle generating the > > keys. > > > > this means we can move aways from using openssl directly in the > > auth_helpers and instead rely on the implementation in > > `proxmox-auth-api`. thus, further unifying key handling in > > `proxmox-auth-api`. this should make it easier to switch keys in the > > future if necessary. > > > > Signed-off-by: Stefan Sterz > > --- > > note that this breaks the following scenario: > > > > - a user installs pbs from a version after this patch was packaged > > - proxmox-backup then creates a new ed25519 authkey > > - the user manually forces a downgrade > > > > proxmox-backup-api and proxmox-backup-proxy will now fail to start as > > they cannot read the, from their perspective, malformed authkey. > > Can we not ensure we remain forward-compatible here, too? I acknowledge > that we probably shouldn't support this kind of scenario, but if we > were to add support for ed25519 keys now (while continuing to use RSA) > we wouldn't ever run into problems in that regard. > > Not sure if it actually makes sense to remain forward-compatible here, > though. > well yeah we could do something like this, but where to we draw the boundary? we don't support downgrades so which version should introduce being able to load and handle ed25519 keys and which version should then start generating such keys? i can separate out the loading and generating part in the next version of this series though, than we can apply them as we see fit. also two notes: 1) such a downgrade scenario can easily be fixed by the admin by removing the authkey. proxmox-backup-api will then just generate a new one next time it is started with the old rsa format. 2) existing installations aren't impacted at all, as no new authkey will generated if one already exists. there is no mechanism that checks if the key is old/insecure/in-efficient or should be upgrade for other reasons. as long as a key exists, no new key is generated. pbs also lacks key-roll-over/key-rotation afaict, so yeah, once and authkey is generated, it is never modified by pbs itself. -- >8 snip 8< --