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 eHNWIkrN2mHGlQAAgWs5BA (envelope-from ) for ; Sun, 09 Jan 2022 12:55:54 +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 GGD0GkrN2mGwJwAAG6o9tA (envelope-from ) for ; Sun, 09 Jan 2022 12:55:54 +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 C9C5537B64 for ; Sun, 9 Jan 2022 12:55:53 +0100 (CET) Received: from localhost ([::1]:55078 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n6Wng-0002jk-Ty for larch@yhetil.org; Sun, 09 Jan 2022 06:55:52 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44694) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n6Wmt-0002jb-4O for guix-devel@gnu.org; Sun, 09 Jan 2022 06:55:03 -0500 Received: from [2a02:1800:120:4::f00:15] (port=41812 helo=andre.telenet-ops.be) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n6Wmq-0001Bj-JC for guix-devel@gnu.org; Sun, 09 Jan 2022 06:55:02 -0500 Received: from [172.20.10.5] ([188.188.4.121]) by andre.telenet-ops.be with bizsmtp id gbuu2600i2cfn6c01buxnr; Sun, 09 Jan 2022 12:54:58 +0100 Message-ID: <710662a46157c2f9ec034ea272351cb1860015d8.camel@telenet.be> Subject: Re: Public key pinning in guix? From: Maxime Devos To: Philip McGrath , guix-devel@gnu.org Date: Sun, 09 Jan 2022 12:54:48 +0100 In-Reply-To: <357034c3-44f2-5ec9-e74a-314412ce2a65@philipmcgrath.com> References: <8dc3fb16db64df6fd71b7ab059c517aa3e779c2b.camel@telenet.be> <357034c3-44f2-5ec9-e74a-314412ce2a65@philipmcgrath.com> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-6L+2tMjO6bW+COF4IYVh" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1641729298; bh=d1sjhzv0Cxv32nnC2R1QZ/H4+cfO8nyNvgTDsI3TOWM=; h=Subject:From:To:Date:In-Reply-To:References; b=jHQiGlUrJa5Xzay9O/PQ1KtM+poXQOfV5qcS+qXUti0Swmh74BvfFn6KwXe9iWq73 1jzV+2OW4+gpe27l5c/N7m/WGXaxV5oGcaFEJQ4sUQJ1YHQ70qLJjWSunxjsJCqbCi RSO9y0KLNgM/Tc/iC75A4CZ2K5ZWKJDmBgB3K8QdbqLaPRxtLlarEdTN182Z54oAAG OnPAh8w3jawRcl+VtUmz7k+Yb17fqJfsoC6DvCIjFArYlUASObnp3kANVW9U919dUy SpJTBytabpXpsLPhkp1gDzksEu83TJfZ9UwyGIkJUYOYLpB2jqYVXVkCEELY9rTKag APdYu9W4bd0gA== X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a02:1800:120:4::f00:15 (failed) Received-SPF: pass client-ip=2a02:1800:120:4::f00:15; envelope-from=maximedevos@telenet.be; helo=andre.telenet-ops.be X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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=1641729354; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=d1sjhzv0Cxv32nnC2R1QZ/H4+cfO8nyNvgTDsI3TOWM=; b=eHMIt8oj9TqCa0dIx1bzkIl84FHYjL4Wrp74cpyI9QodGrR+e1ANlly2NfyWc4tWwYGurd uLXNKwR2rXBT+zFk6C49jBct6fxXUrXuWWI5ruRkbNRvKKYnbZui/t0jrpDccF/piLdO8w 2HkVTpsXao/+Ngz+kom7l9Nbyh49bN1/ih9XO8Yye3f5aqy2hletBXOeCrXsEIbM4kslrM f+Iu38okqCTKCHopvCNRl0t4r/hvxSTlFTJA+3ESS2IWH2gco3Xvuw9FY66dMP5eN+giGO 6X6DEpyLlFLllIuxtH0gNwJ1EhWxI7up9cfSun6gv/9yzkLvK0cwE8OxsYHdKQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641729354; a=rsa-sha256; cv=none; b=stoaYaBh8ivxJUsqfOIODse99IdZnOzwQWOd3rgE21cc9LnJobfjSia9Y0QrrL7XyI21JJ v0HY6eiZ2b+5MyU9sd7JcGcI4fPQe7EFGrngV/+fRU3S+81pZmV1m8pXaaRf30Jc65R0bx MUGXrnCPJk1IoOSZj9SGrkpc93YUQNtWnws2VwdK/gxWDq1em1O8pWZOmbie4a5r/zpEwf 9qh66KH0KCBGiITwW+eGoZNiVZvHl9Iatn9r92NjEmflnCUPEvV5lWE5vnaL9g5+NKZT1K mnijF+wfIAviOLo+ibEFaVtj0R1DHJ4CeQOFEO5H1yhULIXpjPKUA11WOiRAXg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=telenet.be header.s=r22 header.b=jHQiGlUr; dmarc=pass (policy=none) header.from=telenet.be; 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: -11.21 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=telenet.be header.s=r22 header.b=jHQiGlUr; dmarc=pass (policy=none) header.from=telenet.be; 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: C9C5537B64 X-Spam-Score: -11.21 X-Migadu-Scanner: scn0.migadu.com X-TUID: y4xfSeFD8OyH --=-6L+2tMjO6bW+COF4IYVh Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=20 > Key Pinning was deprecated, and support has been removed from major=20 > browser engines by January 2020.[2][3][4] While it seemed like a good=20 > idea for reasons like the ones you list, apparently it not only proved= =20 > very difficult for site administrators to configure, with severe=20 > consequences for mistakes, it also enabled potential ransomware attacks= =20 > and other bad stuff.[6] >=20 > I never followed this feature closely and don't have a strongly-held=20 > opinion on the merits, but, if the "web platform" has deprecated this=20 > feature---more concretely, if it is Considered Harmful by sysadmins and= =20 > servers are configured with the expectation that no one does this any=20 > more---I don't think it would improve reliability for Guix to=20 > 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 =E2=80=98certificate pinning=E2=80=99 (actu= ally 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. The sources you referenced listed a few potential problems with HPKP. Most don't apply to what I propose, and when they do apply, it's at most a denial of server that can easily be fixed: * Using HPKP for Evil: Suppose the attacker tries to perform a RansomPKP attack. Then they need need to either: 1. Modify the pin list in guix to list their public key. If an attacker has commit acces, then I think we have bigger problems. or 2. Do a MITM (or compromise the web server) to some people on #guix that have commit access. Tell people on #guix that the pinned public key is outdated. People on #guix confirm, and commit the new pinned public key. The attacker says to #guix -- pay me $large number, or else. Response #guix -- let's simply revert the pin and inform relevant authorities. Attacker: =F0=9F=98=A5=EF=B8=8F. Note that, to do a MITM, the attacker would have to compromise/corrupt a CA. Public key pinning makes no difference to the difficulty of compromising the web server. So this attack would be at least as hard as when guix doesn't do public key pinning. * Supercookies: the key pins are fixed per commit and the server cannot tell guix to pin something, so there's no state here, so no supercookies. * HPKP Suicide: Web servers don't set a pin, guix does. And guix can decide to change a pin whenever it wants. At most, guix might forget to change the pin to the new public key, but that's easily rectified when noticed (e.g., if multiple people on #guix notice the same public key and the committer notices the same public key). That said, let's not use pins when doing "guix pull", "guix perform-download"=C2=A0or "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. * Things about subdomains on [6]: the domain name match must be exact; a pin for a domain does not imply a pin for subdomains. From the perspective of guix, domains and subdomains would be unrelated. * Does the fact that web browsers deprecated HPKP matter? I don't think so. E.g. [5] says that =E2=80=98However, this exposes as part of the Open Web Platform consider= ations 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.=E2=80=99 I think that "guix download/refresh/import" qualifies as =E2=80=98produc= t level=E2=80=99, or =E2=80=98browser=E2=80=99 here, and that Guix qualifies as OS vendor. I don't think that the bit about sub-CAs, cross-signing, etc. is relevan= t here: we pin public keys, not CAs, and the public key pin can be adjuste= d 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". Also, they suggest using Expect-CT instead. But Expect-CT is less useful= : it's rather complicated, and it only prevents forged certificates from being unnoticed -- it doesn't actually prevent them from being used AFAI= CT. * [4] is just a pointer to [5] * [3] only tells that HPKP isn't supported anymore. The sources they quote are mostly [2] and [5], so I won't cover this source individually. * [2] is mostly saying that HPKP is hard and browsers have been deprecatin= g HPKP and not telling anything new, but what I propose isn't HPKP and it seems rather easy and hard to get wrong to me. * [1] just notes that HPKP is deprecated, it doesn't explain the reasons. I recommend reading a bit about certificate and public key pinning (not HPKP!), it is actually a recommended practice for applications that know in advance which web servers they will contact. Effectively, what I propose would be sort-of a mini-CA for Guix, orthogonal to the PKI system. Greetings, Maxime > -Philip >=20 > [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning > [2]: https://scotthelme.co.uk/hpkp-is-no-more/ > [3]:=20 > http://web.archive.org/web/20200618234723/https://www.fxsitecompat.dev/en= -CA/docs/2019/http-public-key-pinning-is-no-longer-supported/ > [4]: https://chromestatus.com/feature/5903385005916160 > [5]:=20 > https://groups.google.com/a/chromium.org/g/blink-dev/c/he9tr7p3rZ8/m/eNMw= KPmUBAAJ > [6]: https://scotthelme.co.uk/using-security-features-to-do-bad-things/ >=20 --=-6L+2tMjO6bW+COF4IYVh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYdrNCBccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7g7eAQD0oK4v1uJJeLpo+DA/frA9tpmO nQIg/wKptrMzHvxXcgD9E6w7BpyO83H/ZZL4t+WZmXAsCabkMBF32Y28YZQogw8= =W6hP -----END PGP SIGNATURE----- --=-6L+2tMjO6bW+COF4IYVh--