The one thing I don't understand about Tor hidden services is how in heck they could be considered secure without TLS. Like, okay, your identity is secret from the connection itself, but if all your data travels in plaintext over Tor relays, that can't be good, right?
@gargron nah hidden services have their own authentication and encryption layer through the tor network, it's just not HTTPS because that would add a redundant layer on top.
@nightpool @gargron yeah, let's consider *why* we have certificate authorities (which are an awful design)... it's because the domain and "what key belongs to that domain" are decoupled
But in tor onion services, they aren't decoupled... they're bundled very directly together. The name of the tor onion service *is* the key. So it goes straight over a secure connection. No CAs needed!
@cwebber tell me chris if I need domains to be secure and distributed, how could human readable names fit into this system??
@nightpool are you trying to get me to say "petnames"?
Because the answer is petnames https://github.com/cwebber/rebooting-the-web-of-trust-spring2018/blob/petnames/draft-documents/making-dids-invisible-with-petnames.md
@clacke SPKI and SDSI were two complimentary standards that were being worked on for how to do key exchange and trust. It hit most of the right points: web of trust, basically you'd exchange certificates through a petnames system, invented the "canonical s-expressions" data format, no central authority model.
Unfortunately it didn't take off; Netscape bundled CAs inside their product to expedite things (despite warning from TLS community) and the CA problems we have stem from that decision.
@nightpool Fun fact: a collaborator of mine, Christopher Allen, was both largely responsible for TLS/SSL design and also was wholeheartedly against certificate authorities (he wanted SPKI/SDSI)
Thus, I like to call him "TLS CA", a name he doesn't like to be referred to as