What TOFU assumes
Trust on first use means accepting a public key the first time you meet a peer, remembering it, and checking that the same key appears every time after. RFC 7435 describes it as assuming that an unauthenticated public key obtained on first contact and kept for later will be good enough to secure future communication.
SSH is the familiar example. RFC 4251 gives a possible strategy: accept a host key without checking the first time a host is connected, save it in a local database, and compare against it on all future connections. The OpenSSH client keeps those keys in a known_hosts file.
The assumption is narrow. TOFU does not claim the first key is genuine. It claims that if the first key was genuine, any later substitution will be noticed.
Where the risk sits
The weakness is in two places, and RFC 7435 names both.
The first contact. TOFU does not protect against an attacker who can take over the first exchange. The SSH transport specification, RFC 4253, says plainly that a client which accepts a host key without verification leaves the protocol insecure against active attacks. RFC 7469, which specified key pinning for HTTPS, makes the same point about its own design: it is a TOFU mechanism, and it cannot detect an attacker on the first connection to a host.
Key changes. RFC 7435 notes that TOFU makes it hard to tell routine key management from an attack. A legitimate key rotation and an impostor look the same to the client: an unexpected new key.
When the risk is reasonable
TOFU is a sound choice when most of these hold:
- The first contact is hard to intercept. Two people pairing phones face to face are harder to attack than two strangers meeting through a public relay.
- The threat is mostly passive. RFC 4251 notes that an unchecked first connection still protects against passive listening. If your worry is eavesdropping rather than an active attacker sitting in the path, TOFU covers it.
- Key changes stop the session. The protection only exists if a changed key is refused. OpenSSH’s
accept-newsetting does exactly this: it adds keys for new hosts automatically but refuses connections to hosts whose key has changed. - One mistake is cheap and recoverable. Pinning the wrong key for a casual chat contact is a different cost from pinning the wrong key for a device that controls equipment.
When it is not enough
TOFU on its own is a weak fit when the first contact happens over a network an attacker might control, when the relationship carries real authority, or when a person will not be there to look at a warning. In those cases, close the first-contact window with something stronger:
- Compare a fingerprint through another channel. RFC 4251 suggests a fingerprint of the public key, checked by telephone or another external channel. The OpenSSH manual describes showing the fingerprint on first connection so the user can match it against one they already know, and checking it against SSHFP records published in DNS.
- Exchange keys in person. Scanning a QR code from the other person’s screen ties the key to the person standing there.
- Have someone vouch for the key. The second trust model in RFC 4251 has a certification authority sign the name-to-key binding, so the client trusts the authority instead of the first connection. An issuer-signed credential applies the same idea and can be checked offline.
A self-certifying identifier changes the question rather than answering it. When the address is derived from the key, there is no separate name-to-key link to pin, and a mismatch is detected by recomputing. You still need some way to know that the address belongs to the person you meant.
How OpenSSH handles the choices
The StrictHostKeyChecking option in ssh_config shows the trade-offs as settings:
| Setting | New host key | Changed host key |
|---|---|---|
yes | Never added automatically; the user adds it by hand | Connection refused |
ask (the default) | Added only after the user confirms | Connection refused |
accept-new | Added automatically | Connection refused |
no or off | Added automatically | Allowed to proceed, subject to some restrictions |
Only the last row gives up the protection TOFU exists for. The first three differ in how the first key is accepted. They agree that a changed key is a stop.
A short rule
Use TOFU when the first meeting is hard to attack and a wrong guess is cheap, and treat every later key change as an alarm. When either condition fails, confirm the first key out of band or have a trusted issuer vouch for it.