7 ms·

> 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. B

> 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. [0] https://github.com/sigstore/rekor/blob/main/types.md#ssh https://github.com/sigstore/rekor/blob/main/types.md#ssh [1] https://www.techrepublic.com/article/a-new-linux-foundation-open-source-signing-tool-could-make-secure-software-supply-chains-universal/ https://www.techrepublic.com/article/a-new-linux-foundation-...

IYasha 5y ago
Thanks for the insight and links! And really... > relying on a trusted third party ... like GitHub seems like a way better default than PGP's Web of Trust Made me scream: "What??" I'd personally prefer some decentralized torrent-like way of user key distribution.
- majou 5y ago
  What would that look like? Distributing keys is always the hard part.
  - IYasha 5y ago
    Well, I tried to avoid saying blockchain, which is already being implemented https://hackernoon.com/decentralized-public-key-infrastructure-dpki-what-is-it-and-why-does-it-matter-babee9d88579 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.
    - bawolff 5y ago
      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.
      - Spooky23 5y ago
        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.
        bawolff 5y ago
        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.
  - lrem 5y ago
    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".
    - Too 5y ago
      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.
- _wldu 5y ago
  Distribute your public keys via DNS TXT records: https://www.go350.com/posts/age-file-encryption/#age-pki-issues https://www.go350.com/posts/age-file-encryption/#age-pki-iss...
  - judge2020 5y ago
    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.
    - _hyn3 5y ago
      I agree. DNS is its own bundle of insecurity.
    - CameronNemo 5y ago
      Psst. Github has all that stuff too. Just more because it is a growing and changing webapp instead of an ancient, solidified key value store.
bawolff 5y ago
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) All options are sucky in their own way.
- Seirdy 5y ago
  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.
  - bawolff 5y ago
    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.
    - Seirdy 5y ago
      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.

IYasha 5y ago

Thanks for the insight and links! And really... > relying on a trusted third party ... like GitHub seems like a way better default than PGP's Web of Trust Made me scream: "What??" I'd personally prefer some decentralized torrent-like way of user key distribution.

majou 5y ago
What would that look like? Distributing keys is always the hard part.
- IYasha 5y ago
  Well, I tried to avoid saying blockchain, which is already being implemented https://hackernoon.com/decentralized-public-key-infrastructure-dpki-what-is-it-and-why-does-it-matter-babee9d88579 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.
  - bawolff 5y ago
    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.
    - Spooky23 5y ago
      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.
      - bawolff 5y ago
        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.
- lrem 5y ago
  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".
  - Too 5y ago
    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.
_wldu 5y ago
Distribute your public keys via DNS TXT records: https://www.go350.com/posts/age-file-encryption/#age-pki-issues https://www.go350.com/posts/age-file-encryption/#age-pki-iss...
- judge2020 5y ago
  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.
  - _hyn3 5y ago
    I agree. DNS is its own bundle of insecurity.
  - CameronNemo 5y ago
    Psst. Github has all that stuff too. Just more because it is a growing and changing webapp instead of an ancient, solidified key value store.

bawolff 5y ago

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) All options are sucky in their own way.

Seirdy 5y ago
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.
- bawolff 5y ago
  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.
  - Seirdy 5y ago
    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.