💾 Archived View for rawtext.club › ~sloum › geminilist › 002097.gmi captured on 2020-09-24 at 03:21:52. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Michael Lazar lazar.michael22 at gmail.com
Tue Jul 7 04:20:23 BST 2020
- - - - - - - - - - - - - - - - - - -
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 ofexpiring the old ones [2]. As soon as a client connects to a server and acceptsthe new keypair, any old certs should automatically become invalid to thatclient, because they're not the trusted "first-use" certificate anymore. It'snot like a CA system where there can be multiple valid keypairs live at thesame time. This is also true for transferring domain ownership.
An attacker can only continue to exploit a client until they visit the realserver. If the client never visits the real server, the attacker can just swapout the expired certificate with a new self-signed certificate and it will looklike a harmless key rotation. Expiration doesn't gain you anything there.
I get the point about encryption algorithms becoming insecure over time andprivate keys more likely to be stolen. I just don't understand the advantage tokey 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 pairsevery 60 days and issues certificates with a 90 day expiration. I visit yourserver once and then don't come back for 90 days. My client sees that thefingerprint in my local TOFU database is expired, and probably accepts whateverserver sends me. This scenario is dramatically lessened with
1 year expirationtimes, 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 outthe keys on the server.
Honestly though, this sounds like an obtuse way to avoid using a CA. Once youare employing certificate chains is it really self-signed anymore? Generateyour own CA with a 100-year expiration and stick *that* on the USB drive. Youcould even maintain your own certificate revocation list! Utilizing CAs doesnot need to imply trusting the root browser CAs.
best,mozz