Eric Rescorla wrote: > My logic is that if you're going to create something new, it should > be better than what already exists.
Right. But better is not a binary choice in real life. SSL is only "better" if it exceeds all requirements when compared against a product that has only those requirements. One needs to look at the requirements. Tom's requirements didn't include message integrity, if I saw correctly, because he had something in there at a higher layer that covered him there. That's good. Does Tom require certs? No, or *even better* he explicitly outsourced that requirement to another layer, thus allowing the protocol to be simpler. This is a great thing, and my reading of the protocol of SSL - from Eric's book - indicates that SSL would benefit from it too. Does he require replay protection? Is he worried about MITM? What about authenticity? These all need to be established before you can compare any protocol. The whole world doesn't want or need perfect channel security. That's because some parts of the world have different needs. -- iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
