> 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.
I don't believe that is enough. Take for example the SSL 2.0 ciphersuite rollback vulnerability or the SSL 3.0 key-exchange algorithm vulnerability . Any kind of rollback attack is serious, and won't be protected by signatures in the bulk data (and those signature might be weakened by forcing a rollback to a possible weaker version/implementation). > > 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. So maybe I can't replay a complete financial transaction, because at some high layer there is replay prevention, what about replaying some init protocol request? Is that not annoying? Would a bank not care that their ATMs are not working for a day because someone is executing a DoS attack on the lower layers of the protocols of their system? I think not, you need replay protection on both levels. How can a secure socket be dubbed secure if it doesn't protect against these basic attacks? To quote from Wagner and Schneier`s paper, Analysis of the SSL 3.0 protocol: "Replay attacks are a legitimate concern, and as they are so easy to protect against, it would be irresponsible to fail to address these threats." --Anton --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]