From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id MAUWN9fp2mGBOQEAgWs5BA (envelope-from ) for ; Sun, 09 Jan 2022 14:57:43 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id MACvL9fp2mE2nAAAG6o9tA (envelope-from ) for ; Sun, 09 Jan 2022 14:57:43 +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 4E89B397C5 for ; Sun, 9 Jan 2022 14:57:43 +0100 (CET) Received: from localhost ([::1]:55642 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n6Yha-0005Ta-EC for larch@yhetil.org; Sun, 09 Jan 2022 08:57:42 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60890) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n6YhP-0005TO-6o for guix-devel@gnu.org; Sun, 09 Jan 2022 08:57:31 -0500 Received: from [2607:f8b0:4864:20::92d] (port=41649 helo=mail-ua1-x92d.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n6YhN-0004AI-7o for guix-devel@gnu.org; Sun, 09 Jan 2022 08:57:30 -0500 Received: by mail-ua1-x92d.google.com with SMTP id p37so19047283uae.8 for ; Sun, 09 Jan 2022 05:57:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=philipmcgrath.com; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=WpmVoCtMhyQVU5yKH5QbqYmzSMr1eRkkMnZxwno473o=; b=hzbBHr9eUCTjHWf7VOgyjXmItGqhZknk0W85jNjZ4MVdFO87my1pmmmj71f8IFR10i kridIYilNMhZ9jLq4+FbZ/HvDkwz8PpB0MPwwGgNc9fWiV5GflvHhd5nZy7uqBiY1YVV bgzSnP2X8ZrQbzMq6vEGHjiZ8tCiK1Hp78VrRu4WMfkX7PvqKEknUq4HbTB9YdMMY5iZ t8VGzuxsMB2JAQkHD2k6KUrV1OPFs5NVXZkShTwqS4PM06sxi200Kz9zYIvp+rV29vYa bjHOKiy/rHWyo8Q3wbc5eMKP0cS2QpIAdRuH3i4fkLuN8CtNXAsrsQu2Sg5Z6rhem3iH 3IdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=WpmVoCtMhyQVU5yKH5QbqYmzSMr1eRkkMnZxwno473o=; b=S3WL0rPST8373bp9OdN5nz/NhrfiiPEjXfAYEDHwJB8fl6DIVliHUl+EgiKG9intdE gDkC3AYS7n+e1lxrrCYRvQyPcFxIZpEv7PsuoaCRjlGUgNgM7tkpnQ8Ex7M8N46fY4uL 8gEl7COl2Bj/zCElJ2w14tzIgnhl/vcpbik/4LI99IKOntqJdX68Ngh7KIhvbvQG+ycp 3qxTsCbtZEhclqidLM/XTXXB+W7Ff43kUcdCjc1Gao/vB8IRA1e5YJzC52ER0xOhkEtV 7+24VAcVqrDiq3/UIpAlwmWBaR1ym+Y9+55RVd7rdkn16vzJIThlVobUuBcgosw2fUoG Cv5g== X-Gm-Message-State: AOAM532FdzdIsyjrjA8YcWocjFOrMKY6qSMDoOgIpN7dGk3lcgUNLOzY EhZAArnfA8i/FR4/VaWGn0iE8zvU0Vw/knyB X-Google-Smtp-Source: ABdhPJxQTvdc63Dx6SOjWw1ugINvo5RWEqz8euwbTQHWeciMerGR3SYapL3vBueL2YmnnPjgPUz7ZA== X-Received: by 2002:ab0:3807:: with SMTP id x7mr21364802uav.134.1641736647796; Sun, 09 Jan 2022 05:57:27 -0800 (PST) Received: from [192.168.45.37] (c-73-125-89-242.hsd1.fl.comcast.net. [73.125.89.242]) by smtp.gmail.com with ESMTPSA id j129sm1396963vkh.16.2022.01.09.05.57.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 Jan 2022 05:57:27 -0800 (PST) Message-ID: Date: Sun, 9 Jan 2022 08:57:26 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: Public key pinning in guix? Content-Language: en-US To: Maxime Devos , guix-devel@gnu.org References: <8dc3fb16db64df6fd71b7ab059c517aa3e779c2b.camel@telenet.be> <357034c3-44f2-5ec9-e74a-314412ce2a65@philipmcgrath.com> <710662a46157c2f9ec034ea272351cb1860015d8.camel@telenet.be> From: Philip McGrath In-Reply-To: <710662a46157c2f9ec034ea272351cb1860015d8.camel@telenet.be> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::92d (failed) Received-SPF: neutral client-ip=2607:f8b0:4864:20::92d; envelope-from=philip@philipmcgrath.com; helo=mail-ua1-x92d.google.com X-Spam_score_int: -4 X-Spam_score: -0.5 X-Spam_bar: / X-Spam_report: (-0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" 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=1641736663; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=WpmVoCtMhyQVU5yKH5QbqYmzSMr1eRkkMnZxwno473o=; b=ogK3fQIafY9KfE4H7ng5qGxZEE3zamCHm2JxP/yafxnaW52+pvI0P2h9xyDm+6byIqKKw6 vUNnevRV8cdSpykch/tP8afpB75KxGma4gxFYXyNVsIz/TELp+EJiAdycXWfhefA3JefaP FWOfELp+qp0yvbdfNPYIYFaUJDbyygFYz2YoGg+EuHgDhrjuEzLHyIM96VCblTbFTXRUBO YS/GSe+TjYFhmQ2oGaNZVnyXITonqSjDej1ufge9nJjTCWHwGuqKVh+41Yr4a3rUeGsy4I tPpGsva4HKoUoOOhh033q7EddbHPs6g2pC82Ybw6nbVE3s1AvYYOQPCOl7IaGg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641736663; a=rsa-sha256; cv=none; b=EyweFaqpjkNw9dW53H7+bOf2mvu8WZ2auEoBTHbHHORHHrMEPXgGY/0WZVXoh1G6jim3xj PUR1ni6gM3e1dMm1XDYiDL92R057egquUInbOL6uYG7cfE98Lz/90Dep/yYJG3NHYl/BZE ql312+rjpM/xUgEyJqT6J68mT87gG5lpdqefGyFh0t3oSKPyRiu2r9Ca5HCwZfNntaCty9 Lf1vz/qcs5ZbjSlZwnwQcp8wU/AGgMuqP6GqkVk9nu6iCNLADnOtMM1W4Crev0jc/Zq74R 6FIOxbYXLbtW643V0WFUclL8lkmtCJvR54U9CBAzJS3XAFrzDK8JGg8AvtqZ9Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=philipmcgrath.com header.s=google header.b=hzbBHr9e; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -4.61 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=philipmcgrath.com header.s=google header.b=hzbBHr9e; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 4E89B397C5 X-Spam-Score: -4.61 X-Migadu-Scanner: scn0.migadu.com X-TUID: Le45KR5AVvmZ Hi, On 1/9/22 06:54, Maxime Devos wrote: > Hi, > > Philip McGrath schreef op za 08-01-2022 om 11:37 [-0500]: >> This sounds like HTTP Public Key Pinning (HPKP).[1] AIUI, HTTP Public >> Key Pinning was deprecated, and support has been removed from major >> browser engines by January 2020.[2][3][4] While it seemed like a good >> idea for reasons like the ones you list, apparently it not only proved >> very difficult for site administrators to configure, with severe >> consequences for mistakes, it also enabled potential ransomware attacks >> and other bad stuff.[6] >> >> I never followed this feature closely and don't have a strongly-held >> opinion on the merits, but, if the "web platform" has deprecated this >> feature---more concretely, if it is Considered Harmful by sysadmins and >> servers are configured with the expectation that no one does this any >> more---I don't think it would improve reliability for Guix to >> unilaterally revive HPKP. > > It does instead sound like HPKP -- however, what I proposed is in some > sense the inverse of HPKP: > > Instead of a webserver telling the client to pin a certain key, the > client has pinned a certain key in advance. So pinning is Guix' > responsibility, not the web server's. > > What I propose is more close to ‘certificate pinning’ (actually > public key pinning), see e.g. > . > Even then, it's a bit different: the certificate of the server must > be correct according to both the root CAs in $SSL_CERT_DIR > AND the pin list. I agree that the specifics of what you proposed are significantly different than HPKP as implemented by browsers, and also that public key pinning can be quite useful for securing communication with a known server. > That said, let's not use pins when doing "guix pull", > "guix perform-download" or "guix substitute" because "guix pull" > is rather essential and the guix used as the daemon is rarely > updated -- temporarily breaking "guix refresh", "guix download" > or "guix import" is much less a problem. Yes, it seems much lower-risk to have potential breakage of the contributor-oriented commands than the user-facing ones. Also, for many of the user-facing commands, we'll ultimately verify the content of what we download, whether by hash or channel introductions. > * Does the fact that web browsers deprecated HPKP matter? > > I don't think so. E.g. [5] says that > > ‘However, this exposes as part of the Open Web Platform considerations > that are external to it: specifically, the choice and selection of CAs > is a product-level security decision made by browsers or by OS vendor, > and the choice and use of sub-CAs, cross-signing, and other aspects of > the PKI hierarchy are made independently by CAs.’ > > I think that "guix download/refresh/import" qualifies as ‘product level’, > or ‘browser’ here, and that Guix qualifies as OS vendor. > > I don't think that the bit about sub-CAs, cross-signing, etc. is relevant > here: we pin public keys, not CAs, and the public key pin can be adjusted > whenever the website decided to use another public key -- albeit with > a (hopefully brief?) period where it is temporarily inaccessible to > "guix download/refresh/import". The part of the deprecation of HPKP that seems most relevant is that some number of servers---I suspect it may be a large number---are configured under the assumption that no one relies on their using any particular public key. For example, Certbot in its default configuration will rotate to a new public key every time it gets a new certificate, i.e. every two months (30 days before expiration). There is a `--reuse-key` flag, but I don't get the impression that it's widely used unless the server knows clients will rely on the key remaining the same. In fact, I've heard some people argue against reusing keys, as a way to limit the window for damage that could be done by a compromised private key. I'm not trying to take a position on which is the best way to manage a web server, just to point out that I think some servers will change keys very often. If we have some reason to believe that, say, "hackage.haskell.org" will have a stable public key for a reasonably long time, then I'm all for this! And I'm not vehemently against it, anyway: there are mitigations to the potential downsides for end users. But, if we don't know the server's policy, I can imagine even just the seven domains in your original email producing more than one break per month, and I don't know how we'd distinguish a real attack from a routine failure. It's just a hypothesis, though: if anyone has more concrete data, I'd be interested to hear it. -Philip