Re: Public key pinning in guix?

[Philip McGrath <philip@philipmcgrath.com>]

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.
> <https://blogs.fsfe.org/jens.lechtenboerger/2014/03/10/certificate-pinning-with-gnutls-in-the-mess-of-ssltls/>.
> 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