On Sep 22, 2013, at 8:46 AM, Bjoern Hoehrmann <[email protected]> wrote:
> Another point is compatibility with the deployed email infrastructure. > It seems rather trivial these days to establish new communication sys- > tems to hundreds of millions of users; it's been done quite a number of > times in recent years. It seems to disregarding the deployed protocol > might make many desirable features available that are difficult to fit > in with the existing system, like encrypting subject headers and local > parts of addresses. Similarily, some features might be easy to let go > of, asynchronous offline delivery for instance is less interesting in > a always-on world. As much as I dislike breaking compatibility with the existing infrastructure, I think this might be necessary. I see three significant issues trying to make this work in the current system: 1). As you mentioned, the difficulty of integrating these privacy enhancing features in a system that wasn't designed with this in mind. Building a new system with security and privacy as a primary goal would minimize the compromises necessary to maintain compatibility with current infrastructure. 2). Lack of user confidence / awareness. One of the issues I have with the current email infrastructure is that as a user, I have no idea how my messages are handled once they reach my SMTP server. Is SSL/TLS used for the hop to the recipient's server? How about between the recipient and their server? Are the servers actually validating the certificates? Are they subject to a downgrade attack to force the data to be transmitted in the clear? With this proposal - or likely any proposal to update the current system, the user will remain unaware of this information. This is one of the areas where browser developers have done (reasonably) well, providing a visual cue indicating if the data is being protected; while not necessarily perfect, it's far batter than what we have for transport security in the email system. 3). Transition time. This likely would be a very long process - and as per section 3.2, during the transition compatibility takes precedence over security. Given how long this transition will take, it's possible that these concessions will still be in play for a number of years to come - opening gaps that could be used to enable PRISM like programs. If a new system is developed, it would be ideal if it was designed in such a way that gateways could be deployed to provide a compatibility layer with current infrastructure (of course messages traveling across said gateways should trigger some form of alert to the user so they know the security is likely to be reduced). -- Adam Caudill [email protected] http://adamcaudill.com/
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
