We've heard a bit recently from certain parties, especially Ian Grigg, claiming that one should use a "cost/benefit analysis" before using TLS. The claim seems to be that it provides more protection than one really needs.
However, there are many perfectly free (in both senses) TLS implementations, and the added protocol components needed for providing the protection that one may or may not need do not substantially change the cost in practice of running the protocols. We also do not have well studied protocols that provide lesser protection, or a very good analysis of what the security properties are of such theoretical protocols. Developing such protocols with lower standards may be a substantial challenge if our past experience with protocol development is any indication. I would argue that most of the comments made claiming that TLS has a "cost" associated with it are therefore specious. To those making these public statements, this is all a theoretical concern. To me, however, this is a day to day nightmare I face in my practice. Ad hoc protocols are almost universally filled with problems. A few days ago I saw yet another example of an in house ad hoc protocol with what I can only describe as extraordinarily poor properties, which is being used to protect financial transactions. The author of the protocol is a very smart guy who knew nothing about cryptography. He could have easily used TLS, and have used it with much less effort than he actually spent, and would not have had these problems. However, he didn't think he needed something "that complicated", so in the typical way of such things he spent more time and effort doing something far less secure. This is, sadly, a routine sort of discovery. To Ian, it is important that we do a detailed analysis and see whether or not the free (in both senses) and well understood protocol is "cost effective", never mind that the cost is in practice zero, or even negative when compared to other protocols. To me, it is important that we have at-hand cryptographic tools that cover the needs of a wide variety of users, many of whom do not understand the implications of their design decisions and who are not going to gain anything from using a not-really-but-we'll-pretend "less complicated" protocol. By the way, I could make far more money custom designing protocols for the needs of each customer. If there really was a "Guild of Cryptographers" we'd be making money left and right by following the process that Ian in effect recommends and trying to tailor ad hoc protocols for everyone carefully designed to do no more than necessary, and then taking yet more money fixing the mess when it turns out that we're wrong. The era of ad hoc protocols, however, has passed, just as the era where every computer-using company built its own new languages and operating systems has long passed. We no longer have economic justification for that sort of thing, and we no longer have economic justification for everyone rolling their own protocols either. Perry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
