> GitHub acts as a trusted third party here, and you have to trust them not to lie about people's public keys, so it may not be appropriate for all use cases. But relying on a trusted third party with a professional security team like GitHub seems like a way better default than PGP's Web of Trust, which was nigh impossible to use.
Hopefully that's a false dichotomy and the entire Free Software community doesn't end up reliant on Microsoft to host all our keys for us. The article goes on to mention key transparency, though, which does seem like the right solution.
I note that rekor (the transparency log implementation used by sigstore) already supports signing with SSH keys[0], so this TechRepublic article about it[1] from March (which lists only "GPG, x509 and Minisign") is already out of date.
Its not like anyone has ever really come up with a good solution to key distribution. You either trust a central authority (pki), deal with the mess that is web of trust, or blindly trust your first connection and verify the person hasn't changed (tofu).
Honestly it kind of reminds me of the problem of defining "Truth" (in a philosophical sense)
I really liked how keybase [1] approached this issue, their methodology involves generating keys on the client and making it post "proofs" on whatever social media(s) you use. This gives a my identity -> My key relation, and their client (which is open sourced) would verify these proofs clientside. So it's a server aided but still trustless.
Unfortunately the development seems to have ceased after zoom acquired them.
I'd say that DNSSEC records coupled with something resembling WKD makes for a pretty good way to distribute information in a somewhat trusted manner.
Nothing can really replace out-of-band in-person verification because human perception is remarkably difficult to spoof against or MITM. Comparing keys found in two bands, e.g. DNSSEC records and WKD (using TLS verified by the wpki system), is close enough for most threat models: you'd have to compromise DNSSEC and a CA to break that system.
You're still just replacing one central authority with a different one [or i guess 2] (i assume WKD = web key directory, in this context). With the email domain owner (i assume different from the recipent) being a cenral trust point (and if you totally trust them, why not just use mta-sts?).
Now sure, depending on your needs, you might be able to get mild improvements by chosing a different set of trusted parties than the webpki's CAs, but i'm not sure its really that different at the end of the day.
DANE + DNSSEC is much, much stronger than our CA system; if you control the keys (let alone if you go all the way and self host your DNS and mail servers), then you cut out pretty much all the intermediaries you reasonably can. You still have to trust DNS at the end of the day.
MTA-STS depends on webpki and the CA system.
Since not everything leverages DNSSEC yet and it's tricky to implement I'd supplement records with something resembling WKD so you have two bands.
Another possibility is having clients fetch keys over both clearnet and an overlay network (e.g. Tor); this doesn't help if the web server is being MitM'd but at least you have to trust client endpoints a bit less.
The opposite thing is true. DANE is far weaker than the CA system; it is centralized and controlled by parties that aren't accountable for security (and, more importantly, haven't spent the last decade with Mozilla and Google's gun aimed at their head over security issues). DNSSEC's centralized governance can get away with that, because they are de jure owners of the DNS hierarchy, and nobody can make them accountable for anything. You can't revoke .COM. But Google and Mozilla revoked all of Verisign.
I trust Google and Mozilla more than I trust the world governments that control the DNS hierarchy, and I see the actual transparency mechanisms, like CT, that the WebPKI watchdogs have built; unlike with DNSSEC, they aren't simply a theoretical thing that could be built in the future, but rather operate today and have been responsible for numerous detections of misissuance.
Governments do not control DNS in any practical sense. Even if, in theory, the US Department of Commerce could revoke SIDN control over .nl, it would be totally impractical for any directed attack.
Control of Chrome or Google itself is a radically different matter. And with the CA system, there are a 140 other trust points to be attacked.
What is weaker will depend on your perspective and threat model, but if the measure is how easy it would be for the government to create an arbitrary fraudulent SSL certificate, it is objectively much easier than creating an arbitrary fraudulent DNSSEC record.
I can not see how that argument could possibly follow. For the record, I do not think that Google Mail neither easily could, nor should, switch their domain.
Even if the argument is, and I do not think that it is, that domain validated TLS certificates for the .com top domain are the only CA signatures worth considering, it is important to note that it is comparably more straightforward for the government department in question to seize those domain names if needed.
A domain registry PKI where domain ownership is cryptograhically asserted can never be less secure than the heterogenous global CA directory we have today, in any possible sense, not for domain validated certificates.
Sure it can. The domain registry PKI for Google Mail is literally controlled by the USG. They can compel different names to be given to different people, and there's no CT system to monitor it.
s/PKI// and the sentence still holds true. The argument for CT is good, we still need CT logs no matter which kind of PKI we would like to see. But surely the security of other domains outside of Department of Commerce control are of interest too?
Just substitute "US Government" out for whichever government controls the TLD you're thinking of. You'll be no better off; none of them are more trustworthy than Mozilla and Google are.
(I don't find Mozilla or Google to be especially trustworthy, of course; I simply have absolutely no faith in the reverence government agencies have for the sanctity of the DNS. Something about the way they publicly brag about manipulating it probably has a lot to do with it.)
I think the idea that we should vest more Internet trust into the DNS, the one bit of core Internet infrastructure governments have demonstrated any kind of deftness at manipulating, seems, respectfully, pretty nutty.
Do I trust an undisputed monopolist Google to run Internet public key infrastructure more than I trust the United States Government? Yes, I don't even have to think hard on that.
That only creates a link between SSH keys and a domain; It's even worse than relying on GitHub since you have to trust that multiple account haven't been hacked (registrar + DNS) and that neither the DNS host nor the registrar are acting maliciously.
Well, I tried to avoid saying blockchain, which is already being implemented
https://hackernoon.com/decentralized-public-key-infrastructu...
but is resource-heavy. On the second thought, there are potential problems with DHT-like way of distribution (rogue peer overwhelming, etc) I can't seem to find article on this idea (it's pretty old), sorry.
Its kind of missing the point (unless im missing something). The hard part is linking keys to well known identifiers (ensuring that a malicious person can't trick you into thinking you have someone else's key when you really have the evil person's).
Having an append-only store is not the hard part of the problem and there are much better solutions than blockchains for that.
Identifiers are just attributes. If you want to attach a library card, US Passport, refugee id to a blockchain instance of your identity, you can inherit that endorsement.
In NIST speak, you can get a level 2 assurance level (good for most commerce) by collecting two strong identifiers or verifying one.
That does not solve the problem. If it did, we would have solved the problem decades ago
Case in point - pgp supports exactly that - you can have keys, which can have attributes which are endorsed by your key. We've had this since the 90's. It didn't solve the problem back then, reinventing the same thing but worse using blockchains won't solve the problem now.
Distributing small chunks of text sounds like the wrong problem to call "hard". It is building trust in them. Problems with the web of trust are well documented and pretty much boil down to "random people in the Internet turn out to not really be the most trustworthy of mediums".
There’s one final problem even harder than that. Creating a UI that by itself explains this whole complex concept, to a user with an average attention span of 3 microseconds.
Just look at how many scam attacks have been made possible just on urls.
Hopefully that's a false dichotomy and the entire Free Software community doesn't end up reliant on Microsoft to host all our keys for us. The article goes on to mention key transparency, though, which does seem like the right solution.
I note that rekor (the transparency log implementation used by sigstore) already supports signing with SSH keys[0], so this TechRepublic article about it[1] from March (which lists only "GPG, x509 and Minisign") is already out of date.
[0] https://github.com/sigstore/rekor/blob/main/types.md#ssh
[1] https://www.techrepublic.com/article/a-new-linux-foundation-...