Bote mail doesn't have to be used for it's anonymous properties, for me that is just a bonus. For many people it is more than enough to be able to know that it is impossible for anybody else than the intended recipient to read the message thanks to public key addressing. Guaranteed end-to-end security if you can verify the address.
I don't think anything that doesn't fundamentally rely on public key addressing is the (long term) future. There will inevitably issues otherwise, including more issues of the type we have with CA:s today. For those who want to make it more user friendly, nothing stops you from adding a transparent "address translation layer" where servers are involved. When you want to send a message to a person with a human readable address at a server, then the server could then reply with the public key based address to the mail client, and the user would have the option to see what that address is. It could even be logged by the client, with TOFU/POP style trust system that reduces the amount of trust you have to place in the server. No need to trust anybody with plaintext. - Sent from my phone Den 26 nov 2013 21:58 skrev <pjklau...@gmail.com>: > > >From: Stephen Farrell <stephen.farr...@cs.tcd.ie> > >To: "Fabio Pietrosanti (naif)" <li...@infosecurity.ch>, > cryptography@randombit.net > >Message-ID: <5293c66d.4040...@cs.tcd.ie> > > > > On 11/25/2013 08:09 PM, Fabio Pietrosanti (naif) wrote: > > > Let's first cut-off the massive passive traffic analysis, then improve > > > current systems to provide some added protection against metadata, > > > focusing in a far future, when the new system got already wide > > > adoption, make it perfect. > > > > New work on improving hop-by-hop security for email and other things is > > getting underway in the IETF. [1] Basically the idea is to document stuff > > that can be turned on already in current deployments (to the extent > > possible) that gets you PFS and modern TLS ciphersuites. > Pre-working-group > > charter discussion for this is being directed to the > apps-disc...@ietf.org > > list for now, or if folks aren't keen to get on that list, feel free to > > send me comments and I'll make sure they get into the pot. I'll send a > > mail here when the WG is officially kicked off (in a few weeks hopefully) > > with a pointer to the eventual wg mailing list. > > way to go! > Personally I don't see how using a P2P network in any next-gen email system > helps anything. If I send a message to someone, I trust my service provider > to deliver the message to the recipients service provider. If the > communication path is limited to this minimum 3 hops - and each hop is > "secure", then this could be good enough ( considering each service > provider > can be sure that it's talking with the other one directly and securely ). > This is the system architecture proposed for TDMX[2] for a new > transactional > enterprise messaging (yet-to-be standard) system I'm working on. Between > each hop is anyway an anonymous void of untrustworthyness - called the > internet ( adding any application layer complexity seems overkill ). > > If you don't ( and you probably can't ) trust your service provider > (enough) > then there's nothing stopping you running your own. > > Furthermore, Email doesn't need anonymization ( it got to where it is today > without it - it will survive some more) and in fact I argue in [1] that > corporations cannot really use use end-to-end security either. > > [1] > > http://pjklauser.wordpress.com/2013/11/17/why-enterprises-wont-embrace-darkm > ail/ > [2] http://tdmx.org > > >
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
