Re: Public key pinning in guix?

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1: Type: text/plain, Size: 4141 bytes --]

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 
> 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.

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.  Presumably, 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 the 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 
> 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.

Yes, distinguishing an actual MITM from a genuine ‘the public key has
been changed’ seems rather non-trivial.  However, in the script 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=MITM).
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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]