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 YBqrDEgE22G0RAAAgWs5BA (envelope-from ) for ; Sun, 09 Jan 2022 16:50:32 +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 8ONxBUgE22H+HwEAG6o9tA (envelope-from ) for ; Sun, 09 Jan 2022 16:50:32 +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 A677F3B3AC for ; Sun, 9 Jan 2022 16:50:31 +0100 (CET) Received: from localhost ([::1]:34976 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n6aSk-0000Ob-Ry for larch@yhetil.org; Sun, 09 Jan 2022 10:50:30 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43464) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n6a9R-0000je-MB for guix-devel@gnu.org; Sun, 09 Jan 2022 10:30:34 -0500 Received: from [2a02:1800:120:4::f00:13] (port=35354 helo=baptiste.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 1n6a9P-0000KV-4G for guix-devel@gnu.org; Sun, 09 Jan 2022 10:30:33 -0500 Received: from [172.20.10.5] ([188.188.180.65]) by baptiste.telenet-ops.be with bizsmtp id gfWS260031R3YAc01fWSwv; Sun, 09 Jan 2022 16:30:27 +0100 Message-ID: Subject: Re: Public key pinning in guix? From: Maxime Devos To: Philip McGrath , guix-devel@gnu.org Date: Sun, 09 Jan 2022 16:29:48 +0100 In-Reply-To: References: <8dc3fb16db64df6fd71b7ab059c517aa3e779c2b.camel@telenet.be> <357034c3-44f2-5ec9-e74a-314412ce2a65@philipmcgrath.com> <710662a46157c2f9ec034ea272351cb1860015d8.camel@telenet.be> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-5ju4Y23SYiep3lTXDD96" 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=1641742227; bh=JG78wWqbqa8oCIcwwSvIFCCSzfcio8iF4yBz0o+1tQo=; h=Subject:From:To:Date:In-Reply-To:References; b=BbtwSdqVvjM/QdWrEvVukV3p/4YpVC5pdEYAUJwpbpDCjFz+ULLMzUr7kvNR622jn sSmr8X+2zVPYyTPJSldc+5jTl2Ywl48BVvgISQDHcZncGv1XXQmTFmqq3cGrdudEDK sh68Hu2S+tcFAwsgxn4nPkThnkZcAMNfuTG8wn2bPRaUgYSANLyHzw0i+D1My4MEtO 1Rc4HqDSba8er1ftk+osLNeGcaUstKpxYs8mrnsDS3ySdVn3qxmwmOmpbt3QCfllxW Duj3dlTRhLtwTw7PEHxewMCdgek9AUdqf2IkCFlx/0og8xYKlASVW8I3k64klRnZ1P gbtWfCQ1/MOcA== X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a02:1800:120:4::f00:13 (failed) Received-SPF: pass client-ip=2a02:1800:120:4::f00:13; envelope-from=maximedevos@telenet.be; helo=baptiste.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-Mailman-Approved-At: Sun, 09 Jan 2022 10:49:48 -0500 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=1641743431; 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=JG78wWqbqa8oCIcwwSvIFCCSzfcio8iF4yBz0o+1tQo=; b=sXFPTtChksKeMqlD/dTRJm844XCFjevd99CG/2AYCQIcu/B3CjYuEt9PUjji9JO+nSNgzK mDI6jaS3url0Bc1qjSsfq2k2lvwbd9/1icDq+BSDSeMRJXa866faoSDJyHjMtqI5138ixA TjyKuboIHEyi2pMEY1GK6bs9wR3XcB9PZdkhTRO9a3kWOSvjTELc/4y0FVpYZAMa2mYL3w 1to9hCoaVJXvWnSG7zXB16UfbXVYuPIMQQ8mCFr5uT7HoQMGsvqAuEoZQ/Gge+9SiZCit1 rn2XUzouBr7bNnkMSdgRqErFwaXZ/ukXup1/bsTR8xE9KFlSydXFjBiNdR/7rw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641743431; a=rsa-sha256; cv=none; b=LwUkKs539Na0NO05kh1+uifp86es2KaRA1iXbQzLYehdkBhg+7f+p8l8JSDsttQ2tVGl67 u3cRcGiEX3jpHCALTf329xYxPBMKjq9Wkg2ayFH/ImX+8ymyn6s5rw/MQJCkr7AJDxZE8x xBsc2DlQs8/mv7pylH2f1G7qL1t8GceR4LGEOPYmJyWRr8CEU0eKFB7evcql51Uf5Msezd zgZlJXrAmgKQFnaIBOl7YKWuE7UvCvh7eOVpp9MfrBtru8YHyY97IDdsaI4M2oJjhd6pWr LMEg8nsjyYSMPGQre19l6eAiBrPYDqHW9z/k5wF5GfpIGWAYjJVYtY6boXtsEA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=telenet.be header.s=r22 header.b=BbtwSdqV; 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: -6.51 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=telenet.be header.s=r22 header.b=BbtwSdqV; 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: A677F3B3AC X-Spam-Score: -6.51 X-Migadu-Scanner: scn1.migadu.com X-TUID: tvMD+O1b4jC2 --=-5ju4Y23SYiep3lTXDD96 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Philip McGrath schreef op zo 09-01-2022 om 08:57 [-0500]: > The part of the deprecation of HPKP that seems most relevant is that=20 > some number of servers---I suspect it may be a large number---are=20 > configured under the assumption that no one relies on their using any=20 > particular public key. For example, Certbot in its default configuration= =20 > will rotate to a new public key every time it gets a new certificate,=20 > i.e. every two months (30 days before expiration). There is a=20 > `--reuse-key` flag, but I don't get the impression that it's widely used= =20 > unless the server knows clients will rely on the key remaining the same.= =20 > In fact, I've heard some people argue against reusing keys, as a way to= =20 > limit the window for damage that could be done by a compromised private= =20 > key. I'm not trying to take a position on which is the best way to=20 > manage a web server, just to point out that I think some servers will=20 > change keys very often. Yes, indeed. I was wondering if the tools for Let's Encrypt generate new keys or whether they generate new certificates. That said, we could ask the upstreams if they want to do --reuse-key. The number of package updates in a period where the public key remains the same seems to be: * very low for Minetest packages, so I wouldn't pin the public key for content.minetest.net. However, we could do another type of pin: we could pin the Let's Encrypt _root certificate_ for content.minetest.net. =C2=A0Presumably, content.minetest.net will keep using Let's Encrypt for years. It's somewhat weaker than public key pinning, as it assumes Let's Encrypt is reliable, but it stops _other_ potentially compromised/corrupted CA's from interfering. * high for Emacs, Python and R packages, so the=C2=A0the cost of pinning seems low w.r.t. the number of updates, so I believe pinning would work well here. I don't have numbers though. > If we have some reason to believe that, say, "hackage.haskell.org" will= =20 > have a stable public key for a reasonably long time, then I'm all for=20 > this! And I'm not vehemently against it, anyway: there are mitigations= =20 > to the potential downsides for end users. But, if we don't know the=20 > server's policy, I can imagine even just the seven domains in your=20 > original email producing more than one break per month, and I don't know= =20 > how we'd distinguish a real attack from a routine failure. It's just a= =20 > hypothesis, though: if anyone has more concrete data, I'd be interested= =20 > to hear it. Yes, distinguishing an actual MITM from a genuine =E2=80=98the public key h= as been changed=E2=80=99 seems rather non-trivial. However,=C2=A0in the scrip= t for updating the list of pins, we could implement heuristics like: * Contact the site from multiple countries (e.g. using tor). If in different countries there are different public keys, something is wrong. False-positives possible when using certain load balancing schemes, so for some sites this heuristic shouldn't be run. * If the root certificate in the chain changed, things are probably wrong. False-positives are possible when the site changes CA roots, but that's presumably very rare. In these cases, we could send a mail to Minetest, Hackage, etc. people asking if this CA root change is correct. * Automatically send a message to the IRC channel associated with the website, telling that the public key changed, and ask that if they see a different public key, that they report it to guix-devel@gnu.org or #guix on Libera Chat. This one should only be done if upstream doesn't mind us sending these messages of course. These heuristics aren't perfectly but I believe they have few false positives and false negatives in practice (here positive=3DMITM). It would probably be a good idea to look at how TLS compromises in the wild look like. Anyway, seems like there are some possibilities in this area, but personally I'll table it for later. Feel free to implement though if interested. Greetings, Maxime. --=-5ju4Y23SYiep3lTXDD96 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+4iGRcl7gUCYdr/bBccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7m8lAP9vNVHpSuPlGnzvE8Md60GVYIlb E4eAFL3WX5Pu0NOdRQD/YhSSFhlJ9bMAFvguhD4N1HsgQHwi+jeiFng6chiNMAg= =Ku5X -----END PGP SIGNATURE----- --=-5ju4Y23SYiep3lTXDD96--