Comment by tptacek
7 hours ago
Yes, modern fleetwide SSH PKIs all do this; what you're describing is table stakes and doesn't involve anybody delegating any part of their security to a global PKI run by other organizations.
The WebPKI and DNSSEC run global PKIs because they routinely introduce untrusting strangers to each other. That's precisely not the SSH problem. Anything you do to bring up a new physical (or virtual) involves installing trust anchors on it; if you're in that position already, it actually harms security to have it trust a global public PKI.
The arguments for things like SSHFP and SSH-via-DNSSEC are really telling. It's like arguing that code signing certificates should be in the DNS PKI.
DNSSEC PKI does not preclude one from hardcoding specific keys in the client as well.
Providing global PKI and enabling end-to-end authentication by default for all clients and protocols certainly would make the internet a safer place.
So now we're running two PKIs? What does the second one do? Why not three?
I would really appreciate it if you would respond to my points instead of just moving on to another argument.
Do you hardcode Github and AWS keys in your SSH config? Do you think it would be beneficial to global security if that happened automatically?
1 reply →