Thanks for the explanation. It seems like there are two cases here:

1. Things that use TLS and hence the WebPKI 2. Other things.

None of what you've written here applies to the TLS and WebPKI case, so I'm going to take it that you're not arguing that DNSSEC validation by clients provides a security improvement in that case.

That leaves us with the non-WebPKI cases like SSH. I think you've got a somewhat stronger case there, but not much of one, because those cases can also basically go back to the WebPKI, either directly, by using WebPKI-based certificates, or indirectly, by hosting fingerprints on a Web server.

▲

tptacek 4 hours ago | parent | next [-]

In practice, fleet operators run their own PKIs for SSH, so tying them to the DNSSEC PKI is a strict step backwards for SSH security.

There may be other applications where a global public PKI makes sense; presumably those applications will be characterized by the need to make frequent introductions between unrelated parties, which is distinctly not an attribute of the SSH problem.

▲

indolering 4 hours ago | parent [-]

And for everyone else that just wants to connect to an SSH session without having to setup PKI themselves? Tying that to the records used to find the domain seems like the obvious place to put that information to me!

DNSSEC lets you delegate a subtree in the namespace to a given public key. You can hardcode your DNSSEC signing key for clients too.

Don't get me started on how badly VPN PKI is handled....

▲

tptacek 3 hours ago | parent [-]

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.

▲

indolering 3 hours ago | parent [-]

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.

▲

tptacek 3 hours ago | parent [-]

So now we're running two PKIs? What does the second one do? Why not three?

▲

indolering 3 hours ago | parent [-]

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?

	▲	tptacek 3 hours ago \| parent [-]
		No, we run a fleet with thousands of physicals and hundreds of thousands of virtuals, of course we don't hardcode keys in our SSH configuration. Like presumably every other large fleet operator, we solve this problem with an internal SSH CA. Further, I haven't "moved on to another argument". Can you answer the question I just asked? If I have an existing internal PKI for my fleet, what security value is a trust relationship with DNSSEC adding? Please try to be specific, because I'm having trouble coming up with any value at all.

▲

indolering 4 hours ago | parent | prev [-]

> None of what you've written here applies to the TLS and WebPKI case, so I'm going to take it that you're not arguing that DNSSEC validation by clients provides a security improvement in that case.

It would benefit the likes of Wikileaks. You could do all the crypto in your basement with an HSM without involving anyone else.

> That leaves us with the non-WebPKI cases like SSH. I think you've got a somewhat stronger case there, but not much of one, because those cases can also basically go back to the WebPKI, either directly, by using WebPKI-based certificates, or indirectly, by hosting fingerprints on a Web server.

But do they? That requires adding support for another protocol.

I would like to live in a world where I don't have to copy/paste SSH keys from an AWS console just to have the piece-of-mind that my SSH connection hasn't been hijacked.