On Wednesday, Jul 9, 2003, at 14:19 US/Eastern, Zooko wrote:
Ian Grigg wrote:
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'll try to make this concrete. My thesis is different than Ian's -- rather
than saying that those apps need less than what TLS offers, I say that they
need more! (So that each app need no longer implement the added features
From what I can see, both IanG and Zooko are making an end-to-end argument: if one requires end-to-end replay (integrity/confidentiality) protection, one does not necessarily benefit from the corresponding point-to-point mechanisms that SSL provides.
IIRC SSL provides secure, point-to-point, ordered byte streams. Systemics' SOX tries to provide secure, end-to-end, (partially) offline, non-repudiable, unordered, at-most-once transactions. (Roughly.)
There is no benefit in using SSL underneath SOX: if SOX is insecure, using SSL won't help (except perhaps of obfuscate the problems) and if SOX is indeed secure, it provides all the security functionality that is required.
There are plenty other situations in which use of SSL is counterproductive or impossible. Various group communication and replication algorithms (BFT) come to mind, as well as various UDP-based applications.
Reinventing SSL is not such a good idea (although -having studied the SSL spec a few years ago- I can see why the SSH designers went that route). Blindly assuming everyone can or should use SSL is an equally bad idea.
[Disclaimer: My understanding of SSL/TLS is incomplete. Eric Rescorla's book
is on my amazon wishlist. Please be polite when correcting my errors, and
I'll do the same for you.]
That is fine, my understanding isn't perfect either. You should not need a book to be able to use or discuss an open protocol like SSL/TLS. As Eric Rescorla said: "What makes developer's lives simple is simple APIs".
[good stuff elided]
P.S. I am aware that TLS encompasses the notion of stored or cached sessions,
originally conceived for performance reasons. Perhaps a higher-level
abstraction could be built by requiring each party to use that facility in a
It might get you from per-session protection to across-all-session protection. But it can never protect against injecting two messages with identical meaning (replay) into the SSL layer twice.
-J -- Jeroen C. van Gelderen - [EMAIL PROTECTED]
War prosperity is like the prosperity that an earthquake or a plague brings. The earthquake means good business for construction workers, and cholera improves the business of physicians, pharmacists, and undertakers; but no one has for that reason yet sought to celebrate earthquakes and cholera as stimulators of the productive forces in the general interest. -- Ludwig von Mises
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]