Eric Rescorla wrote: > You keep harping on certs, but that's fundamentally not relevant to > the point I was trying to make,
OK! > which is whether or not one provides > proper message integrity and anti-replay. As far as I'm concerned, > there are almost no situations in which not providing those services > is appropriate. That kind of infrastructure is already built into > SSL and shouldn't be reinvented. Welcome to the applications world! Integrity: Financial protocols that use crypto (as opposed to ones abused by crypto) generally include signed messages. The signature provides for its own integrity, as well as a few other things. Replay: One of the commonest problems in HTTPS sites is replay failure. The solution is well known out in the real world - you have to have replay prevention at the higher layers. (Credit card processors have replay prevention too!) So, some protocols don't need replay prevention from lower layers because they have sufficient checks built in. This would apply to any protocols that have financial significance; in general, no protocol should be without its own unique Ids. I wouldn't say that this is a good reason to take these features out of SSL. But assuming they are "needed" is a cautious assumption, and assuming that SSL meets the needs for replay & integrity makes even less sense when we are dealing with a serious top-to-bottom security model. It's simply the case that a serious financial protocol would have to have its own replay & integrity, because its threat model and failure model is so much broader than SSL's. For example, a serious payments scenario works across end-to- end, and assumes that nodes on both end-points can be compromised and/or faulty. And, it's not only just faults, many higher layers actively replay as part of the protocol. SSL just doesn't address the security needs of protocols as well as all that. Where I've seen it used, the core need for it is privacy of the data stream, not anything else. (As a sort of oxymoron, a payments or similar protocol that didn't have its own replay & integrity would not work. Ideally, a good test of a payments protocol is to see if it would work over unprotected UDP or email. Some do and some don't.) -- iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]