> If users demand an insecure mode, it is because your secure mode has bad user > interface.
I'm actually thinking about things like web services where the "user" isn't someone sitting in front of a UI, but a programmer, or a team of programmers, testers, and operational personnel. It's easy to hand wave about how secure *should* be easy, but in practice it's not, when you need to provision mutual authentication without any previously shared trust infrastructure or secrets, do it twice for testing and production, manage separation of duties between dev, test and ops, when TOFU isn't good enough for your auditors and you're trying to provide libraries and APIs for your protocol in various flavors and for multiple frameworks on C, Ruby, Python, PHP, .NET, VisualBasic, Java, Scala, ECMAScript or whatever the hot new thing is today. (and even if you do give them libraries, half of the devs will try to implement it themselves because crypto is cool) Managing all this friction isn't strictly the job of the crypto protocol, but this meta-layer can exert considerable force on protocol designs. Responding to it by saying, "H3", doesn't always cut it with the people paying your salary, even with a great argument about how bad an insecure mode will be in the future - because there is no future if you go out of business because you can't onboard customers. I'm saying there are better ways to manage this common design pressure and accommodate the real needs of your customers than by adding multiple modes or negotiation to a protocol. -Brad _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
