On Mon, Sep 23, 2013 at 3:30 AM, Jon Callas <[email protected]> wrote:
> . > > > > By PRISM-class I mean an attack that attempts pervasive surveillance > with budgets in excess of $100 million rather than the PRISM program in > particular. > > Rather than using a word like PRISM-class to mean something other than > what it sounds like (which is a good idea), invent a new term or just say > what you mean. Maybe that is the case inside the field. Outside the field, PRISM has a different meaning, one that is very widely understood and tapping into that is a good way to build critical mass. > > Neither OpenPGP nor S/MIME is capable of providing protection against > this class of attack because they are not widely enough used. We can only > hope for these to be useful if at least 5% of Internet users start sending > mail securely. > > I understand what you are trying to say, but you have now created an > objection that all new protocols fail against. So now nothing can meet the > requirements because it has to be born with a user base. > I don't think we can expect S/MIME or OpenPGP to get to 5% by just waiting for the inevitable success like we have been doing for 20 years. I have been saying that something new should use components that are > available now. Each of OpenPGP and S/MIME suffer from nothing more than > cruft accumulated over time and things we can do better from the start > because we have an additional 20+ years of thought and techniques. > > Throwing them out because we can and should just do better is both bold > and simple. > Umm, not sure what you mean. I don't want to have to revisit the interfacing to mail part of the problem which is where most of the horror show ends up being. And there are a billion+ email clients that are capable of receiving encrypted email that are worth building on. I don't think it is the accumulated cruft that is the problem. It is the lack of key discovery, security policy and the monolithic trust model. -- Website: http://hallambaker.com/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
