4 ms·

That is a terrible security assessment and it is an awful model for the web. OpenSSH's TOFU works in its specific context primarily because SSH targets have be

That is a terrible security assessment and it is an awful model for the web. OpenSSH's TOFU works in its specific context primarily because SSH targets have been connected to beforehand and you can't place an evil proxy between. In order to prevent issues with TOFU, we've got SSHFP DNS records (so, trusting DNSSEC). Now with the web, it's already rather ridiculous to suggest that it's not a terrible security model to not visit any new websites on untrusted connections. Plus the seeming lack of alternative methods (like SSHFP/TLSA + DNSSEC) to establish trust with untrustworthy networks (which well, most networks should be considered as).

tptacek 4y ago
Giving the DNS PKI any influence over your SSH connections seems insane, since there is literally no reason whatsoever the DNS root and TLD operators should have any say whatsoever in how you connect to your own servers. If you're worried about key continuity issues, do what large SSH fleet deployers do, and use certificates. Key continuity was the motivating use case for SSH certificates, before they were used to do MFA/SSO logins for users. I don't disagree with the analysis of Gemini's trust model; I think you're right that key continuity doesn't work on the scale of the public web. Of course, I don't think DNSSEC has any answers here, either; the Web PKI is probably the best thing we've got right now.
- Avamander 4y ago
  I just highlighted the fact that OpenSSH (which was an inspiration to the Gemini people) finds this an issue and have devised solutions. You and everyone else are absolutely free to not to trust DNSSEC and deal with the pitfalls of TOFU-over-internet in some other way. Though in theory, just using SSHFP+DNSSEC and those operators being malicious shouldn't degrade SSH's security, it should only hinder the same TOFU. In which case I suspect people would fall back to the Web PKI to look up the reason for the mismatch.

tptacek 4y ago

Giving the DNS PKI any influence over your SSH connections seems insane, since there is literally no reason whatsoever the DNS root and TLD operators should have any say whatsoever in how you connect to your own servers. If you're worried about key continuity issues, do what large SSH fleet deployers do, and use certificates. Key continuity was the motivating use case for SSH certificates, before they were used to do MFA/SSO logins for users. I don't disagree with the analysis of Gemini's trust model; I think you're right that key continuity doesn't work on the scale of the public web. Of course, I don't think DNSSEC has any answers here, either; the Web PKI is probably the best thing we've got right now.

Avamander 4y ago
I just highlighted the fact that OpenSSH (which was an inspiration to the Gemini people) finds this an issue and have devised solutions. You and everyone else are absolutely free to not to trust DNSSEC and deal with the pitfalls of TOFU-over-internet in some other way. Though in theory, just using SSHFP+DNSSEC and those operators being malicious shouldn't degrade SSH's security, it should only hinder the same TOFU. In which case I suspect people would fall back to the Web PKI to look up the reason for the mismatch.