Tom Weinstein wrote: > The economic view might be a reasonable view for an end-user to take, > but it's not a good one for a protocol designer. The protocol designer > doesn't have an economic model for how end-users will end up using the > protocol, and it's dangerous to assume one. This is especially true for > a protocol like TLS that is intended to be used as a general solution > for a wide range of applications.
I agree with this. Especially, I think we are all coming to the view that TLS/SSL is in fact a general purpose channel security protocol, and should not be viewed as being designed to protect credit cards or e-commerce especially. Given this, it is unreasonable to talk about threat models at all, when discussing just the protocol. I'm coming to the view that protocols don't have threat models, they only have characteristics. They meet requirements, and they get deployed according to the demands of higher layers. Applications have threat models, and in this is seen the mistake that was made with the ITM. Each application has to develop its own threat model, and from there, its security model. Once so developed, a set of requirements can be passed on to the protocol. Does SSL/TLS meet the requirements passed on from on high? That of course depends on the application and what requirements are set. So, yes, it is not really fair for a protocol designer to have to undertake an economic analysis, as much as they don't get involved in threat models and security models. It's up to the application team to do that. Where we get into trouble a lot in the crypto world is that crypto has an exaggerated importance, an almost magical property of appearing to make everything safe. Designers expect a lot from cryptographers for these reasons. Too much, really. Managers demand some special sprinkling of crypto fairy dust because it seems to make the brochure look good. This will always be a problem. Which is why it's important for the crypto guy to ask the question - what's *your* threat model? Stick to his scientific guys, as it were. > In some ways, I think this is something that all standards face. For any > particular application, the standard might be less cost effective than a > custom solution. But it's much cheaper to design something once that > works for everyone off the shelf than it would be to custom design a new > one each and every time. Right. It is however the case that secure browsing is facing a bit of a crisis in security. So, there may have to be some changes, one way or another. iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]