On Wed, Oct 23, 2013 at 11:22 AM, Paul Wouters <[email protected]> wrote: > On Wed, 23 Oct 2013, DataPacRat wrote:
>> My general thought, as of the start of this thread, is that such >> attacks could be made much harder to implement and much less effective >> by massively increasing the number of CAs (essentially, by turning >> everyone into a CA). > > That's basically what DANE does. Everyone becomes their own CA within > their own domain, by securely (DNSSEC) publishing TLS public keys. > The only defense against a "subpoena attack" is not outsourcing your > end to end encryption. That's what we need to facilitate. I think I see a differing assumption between DANE and RPKI, and the model I'm using. Both of those security systems seem to be aimed at provably linking a domain name with a particular server, so that when you go to 'gmail.com' you're not secretly being redirected to some other server which decrypts your private email. But if no domain name is involved, neither of those systems applies. I'm thinking of a different layer of security: the end-user, rather than their ISP. While many companies and some people run their own domain names, an increasing number of people don't even bother having email addresses anymore - they have accounts at an ever-shifting collection of social media sites, each of which has different capabilities, each of which uses different security procedures. Proving that the tweets sent by @DataPacRat are from the same person as the posts of facebook.com/DataPacRat, and both are sent by someone posting to an otherwise-anonymized Tor-based bulletin board, seems, to me, to be a related but slightly different problem than securing twitter.com and facebook.com themselves. Put another way - I'm trying to find a security solution that includes sites with URIs resembling randomstring.onion , as well as whatever random pseudo-URIs will have been invented in five to ten years. With luck, such a solution will be broad enough to cover more ordinary internet usage, as well. As .onion addresses don't use the DNS system, DNS-based security systems aren't quite general enough for what I'm hoping to aim for. A highly distributed CA-like system /might/ be broad enough to do the trick (not to mention many other tricks); it's possible I'll have to look somewhere else, or even that it's not a soluble problem. There don't seem to be many people thinking in this direction, so I'm doing what I can to figure out as much as I can, in case I manage to collect enough ideas to assemble into a useful new pattern. Signed vCards seem as if they'd be a handy tool to build any such solution on, as they allow for keys to be asserted as being linked to arbitrary ID strings (including any given URI or pseudo-URI). Working out a system for easy use, exchange, and storage of Signed vCards is... still an open problem. Since enduser-to-enduser security would help reduce pervasive passive monitoring, and I've started getting a better handle on IETF mailing lists and working groups, I've brought up the idea here, in hopes of evoking as many potentially useful ideas as I can. I'm all too aware that this logic chain may have fallen off the rails at just about any point in the above-described thought processes, so I'm also trying to keep an eye out for any alternative approaches that can handle non-DNS-based identifiers. We now return you to your regularly scheduled mailing list. Thank you for your time, -- DataPacRat "Then again, I could be wrong." _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
