Removing expiry dates for TOFU

[Michael Lazar]

On Sun, Jul 5, 2020 at 1:17 PM Solderpunk <solderpunk at posteo.net> wrote:
> Using the same keypair for a very long time is generally considered a
> bad idea, as it increases both the risk of key compromise and the
> duration for which a stolen key can be exploited. There's also the issue of
> ownership of domain names changing over long timespans, and former legitimate
> domain owners being able to impersonate new legitimate domain owners with old
> certificates. Even CA certificates have expiry dates.

Is this actually true for TOFU certificates? SSH fingerprints don't expire [1].

Servers can still rotate key pairs without introducing the attack vector of
expiring the old ones [2]. As soon as a client connects to a server and accepts
the new keypair, any old certs should automatically become invalid to that
client, because they're not the trusted "first-use" certificate anymore. It's
not like a CA system where there can be multiple valid keypairs live at the
same time. This is also true for transferring domain ownership.

An attacker can only continue to exploit a client until they visit the real
server. If the client never visits the real server, the attacker can just swap
out the expired certificate with a new self-signed certificate and it will look
like a harmless key rotation. Expiration doesn't gain you anything there.

I get the point about encryption algorithms becoming insecure over time and
private keys more likely to be stolen. I just don't understand the advantage to
key rotation + expiring the old keys vs. simple key rotation by itself.

[1] https://tools.ietf.org/html/rfc4716

[2] The attack vector being something like this: Your server rotates key pairs
every 60 days and issues certificates with a 90 day expiration. I visit your
server once and then don't come back for 90 days. My client sees that the
fingerprint in my local TOFU database is expired, and probably accepts whatever
server sends me. This scenario is dramatically lessened with > 1 year expiration
times, but why allow it to happen at all?

> One idea I had, which could be neat for people who are really serious
> about good, long-term identity management without CAs, is the following:
> generate a key pair, for use as an ephemeral signing key, and a
> self-signed certificate for the public key with 100 years of validity.
> Then generate 100 additional keypairs, and use the signing key to sign
> certificates for them with a validity of, say, 1 year each, and
> consecutive validity periods.  Permanently delete the signing key, but
> keep the self-signed certificate.  Move all the 1 year keys to a USB
> stick, and transfer them one at a time, as they become valid, to your
> server.  For the next 100 years, serve up a two certificate long chain,
> with the self-signed cert for the signing key, plus your currently
> active 1 year cert signed with the signing key.  Once a client
> TOFU-accepts the signing key's certificate, they'll be able to validate
> all the annual key roll overs as originating from the same party, even
> if they don't visit your site for 10 years at a time.  Someone who
> breaks into your server can steal this year's key, but not any future
> keys, because they're on the USB stick, so their ability to impersonate
> you is strictly time-limited.  Nobody can steal the original signing key
> and make their own certificate which will be accepted by TOFU clients,
> because it's been deleted.  Hijacking this identity basically requires
> stealing the physical USB key.  This sounds like a lot of work, but
> generating all the keys and certs could be trivially automated.

You would need some overlap in the validity periods to allow time to swap out
the keys on the server.

Honestly though, this sounds like an obtuse way to avoid using a CA. Once you
are employing certificate chains is it really self-signed anymore? Generate
your own CA with a 100-year expiration and stick *that* on the USB drive. You
could even maintain your own certificate revocation list! Utilizing CAs does
not need to imply trusting the root browser CAs.

best,
mozz