On Fri, Nov 28, 2014 at 06:09:20PM -0800, coderman wrote:
for my second act as devil's advocate, i declare that it is unreasonable to demand users recognize or understand a threat model.
thus every system must be engineered to withstand the most difficult and well resourced threats, such that a solution covers all threat models sufficiently.
Agreed on the first point, disagree on the second. Any system that claims to be secure will attract uses that are inappropriate to its assumptions. Documentation is not enough to dissuade this. A colleague and I, both interested in modern cryptographic systems, started to collaborate on a new project, using Pond. Months later, we realized that we had communicated useful information early on, over Pond exclusively, and the "social norm that communications are deleted after a few days" resulted in us losing important notes about the early days of our project. Even though it was clearly documented and I had simultaneously advocated Pond to other experimental users for exactly this feature, I didn't think through the consequences of this design feature for my use case. I didn't even realize that I *had* a use case, until much later. For this scenario, it turns out we wanted a modern secure communication system more like Prate, https://github.com/kragen/prate . Except perhaps with email-sized-message semantics rather than chat semantics (or email in addition to chat?). Generalizing from this specific example, you can find many other examples of a security system being used outside of its designed envelope. ssh is widely used for login to ephemeral hosts, reducing TOFU to single session duration. ssh is used with github as merely a bidirectionally-key-authenticated transport layer ("git clone git@github.com:kragen/prate") rather than its original remote shell purpose. HTTPS x509 DV certificates have the mostly verstigal x.500 (iirc?) Location/organization/etc naming support, the CN/sAN fields being nearly the only operative ones. HTTPS virtually never uses the many varied client authentication mechanisms supported in TLS (client certificates, SRP, etc), instead Rails and the many other web-app frameworks implement user authentication over the top using passwords and cookies etc. -andy