Earlier quoted context omitted.
I'm going to skip the long part, but what you're basically requesting is that everyone must trust the countries operating their ccTLDs. Does that sound reasonable? I don't think so.
Don't we already implicitly have that sort of trust at the moment with TLS certs considering that proof of ownership via DNS is quite common? Actually, any domain-based validationi, i.e., also HTTP-01, is going to be flawed if you don't trust the registries.
We need better support for SSH host certificates
141–150 of 161 posts
Re: We need better support for SSH host certificates
#142Earlier quoted context omitted.
You really never ssh from one remote server to another?
SSHing from one remote server to another won’t be possible in a lot of environments due to network segmentation. For example, it shouldn’t be possible to hop from one host to another via SSH in a prod network supporting a SaaS service. Network access controls in that type of environment should limit network access to only what’s needed for the services to run.
Re: We need better support for SSH host certificates
#143Earlier quoted context omitted.
I'm going to skip the long part, but what you're basically requesting is that everyone must trust the countries operating their ccTLDs. Does that sound reasonable? I don't think so.
Trusting the country that operates the ccTLD of your website is a much better situation than having to trust all the countries that have CAs operate in them. A malicious CA in one country can issue a fraudulent certificate for a site in another country, whereas the people operating .ru can't affect the records for example.us so the blast radius is limited by design. Moreover, no one is required to use a ccTLD, and th…
Sure and they'll be quickly mistrusted. You can't really revoke DNNSEC trust of an ccTLD operator.
> Moreover, no one is required to use a ccTLD, and there are hundreds of gTLDs to choose from, or you could even run one yourself if necessary.
This is bypassing a dangerous design, at best.
Re: We need better support for SSH host certificates
#144Anyone else relying on GSSAPI key exchange & authentication instead?
Re: We need better support for SSH host certificates
#145Earlier quoted context omitted.
The CA system is just multiple points of failure instead of one. One is better.
No, because if one CA is broken only the certificates it authored are vulnerable. It takes more to break the entire system.
Re: We need better support for SSH host certificates
#146Anyone else relying on GSSAPI key exchange & authentication instead?
I assume that means Kerberos, as opposed to GSSAPI mechanisms like (the moribund?) ABFAB, (now rightly deprecated?) Globus GSI, or even NTLM. I've used Kerberos GSSAPI with ssh long ago, but no longer can at work. Incidentally, people arguing for X.509 might consider why GSI is such a dirty word in the research computing circles I know! I think it's still widely used in HEP, and even the US Access system, though.
Re: We need better support for SSH host certificates
#147Earlier quoted context omitted.
At work, we switched to Step CA [1] about 2 years ago. The workflow for our developers looks like: 1. `ssh client-hosts-01` 2. Browser window opens prompting for AzureAD login 3. SSH connection is accepted How is that simple, compared to `ssh -i .ssh/my-cert.rsa someone@destination --> connection is accepted, here's your prompt` ?
What if you're ssh-ing from a headless client, like a raspberry pi or a VPS?
Re: We need better support for SSH host certificates
#148Earlier quoted context omitted.
No, because if one CA is broken only the certificates it authored are vulnerable. It takes more to break the entire system.
So? If an authoritative DNS server operator is broken, only the domains below that operator (in the DNS hierarchy) could be impacted.
In contrast, there is no unique "root CA" that can fail.
Re: We need better support for SSH host certificates
#149Earlier quoted context omitted.
The CA system is just multiple points of failure instead of one. One is better.
No, because if one CA is broken only the certificates it authored are vulnerable. It takes more to break the entire system.
DNS root key compromise breaks the entire system until it is replaced.
Not seeing a huge difference.
Re: We need better support for SSH host certificates
#150Earlier quoted context omitted.
No, because if one CA is broken only the certificates it authored are vulnerable. It takes more to break the entire system.
A CA can sign for any site. I'd say a single CA compromise breaks the entire system until it is revoked. DNS root key compromise breaks the entire system until it is replaced. Not seeing a huge difference.
It is not possible to revoke the DNS root, and there are no widely deployed alternatives. The incentive to do the right thing isn't as hard: it's just "good" guys doing the right stuff. If something wrong happens, where will you go ? Nowhere else.