[RFC] Preferentially TOFU certificate authorities rather than host keys
Damien Miller
djm at mindrot.org
Wed Oct 16 13:58:19 AEDT 2024
On Mon, 14 Oct 2024, Matthew Garrett wrote:
> There's currently no way to express trust for an SSH certificate CA other
> than by manually adding it to known_hosts. This patch modifies the automatic
> key write-out behaviour on user verification to associate the hostname with
> the CA rather than the host key, allowing environments making use of
> certificates to update (potentially compromised) host keys without needing
> to modify client configuration or force users to update their known_hosts.
Thanks - this is an intriging idea. I'll need to consider it a bit;
TOFU of CA trust anchors is not a common pattern and both the UI and
the general ramifications need to be thought through.
> Posting at this point primarily for discussion rather than submission -
> if this is something that seems desirable then we probably also want the
> ability for servers to revoke old certificates. I have some patches for
> that, but don't want to spend too much time cleaning them up unless this
> seems like something that stands some chance of being accepted.
>
> This was inspired by
> https://github.blog/news-insights/company-news/we-updated-our-rsa-ssh-host-key/
> - github accidentally leaked their RSA private key into a public repo
> and immediately rolled over to a new one. This created significant
> disruption to client systems which fired noisy warnings about host keys
> having changed, and organisations were forced to reassure their users
> that in this specific case they should go ahead and delete the old
> fingerprint but should still in general not do that. Everyone had a bad
> day.
>
> If Github had been using certificates, and if we had a way to engender
> trust in certificate CAs, they could have rolled to a new key and
> certificate signed with the same (hopefully offline) CA key with zero
> impact on users. Ideally they'd also be able to push a signed revocation
> statement that would invalidate the old certificate.
TOFU of CA trust anchors could help here, but we already have a graceful
key rotation mechanism that is at least partially enabled by default.
It isn't as effective as I'd like to be because of a number of corner
cases that have yet to be filed smooth. See client_input_hostkeys() in
clientloop.c for the whole mess.
In the case of the Github incident, one thing that drastically reduced
its effectiveness was the old default of disabling the rotation when
multiple hostnames were found for the same key. This interacted badly
with the old default of CheckHostIP, which caused both the name and
address of hosts to be recorded in known_hosts.
The CheckHostIP default has since been changed, but its droppings are
still in lots of known_hosts files...
-d
More information about the openssh-unix-dev
mailing list