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 itself.) [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.] Replay prevention in SSL/TLS is related to the concept of "sessions". A given sequence of bytes can't be replayed within a given session, nor replayed in a different session, nor can a session itself be replayed in whole or in part. Sounds good, right? But suppose at the higher layer you have a message which you wish to send, and you wish to ensure that the message is processed by the recipient at most once, and you wish to keep trying to send the message even if you suffer a network failure. For example: "<transfer><outaccount_id>100876</o><inaccount_id>975231</i> <currency>USD</c><amount>1000.00</a></transfer>". Assume that the user has delivered the instructions to you, through clicking on a GUI, sending you a signed snail mail letter, or whatever, and now it is your job to convince the computer at the other end of the TLS connection -- your "counterparty" -- to implement this transaction. Now if you send this message, and you get a response from your counterparty saying "<transfer_status>completed</transfer_status>", then you are finished. But suppose you send this message, and then the TCP connection breaks and the TLS session ends? You don't know if your counterparty got the message, much less if he was able to implement the transaction on his end. If you open a new TLS connection and send the message again, you might inadvertently transfer *two* thousand dollars instead of one. Now the state of the art in apps like these, as Ian has pointed out, is to implement replay protecton at the app level, for example adding a transaction sequence number to the message. To me, this sounds like an opportunity for another layer, which provides a general solution to this problem. (I would expect Ian's SOX protocol to be one such design.) Of course, not all problems are amenable to a general, reusable solution. Not even when, as in this case, almost all applications independently re-invent a special-purpose solution. The particular sticking point in this problem seems to be state management -- you have to be careful that one side or the other isn't stuck with excessive requirements to store information in order to complete the protocol. As Ian mentioned, apps can have several other possible requirements in addition to this one (which I call "retriability"). Consider a situation where the message has to be printed out and stuck in a folder for a lawyer to review. If the integrity guarantee is encoded into a long-term, multi-packet TLS stream, then this guarantee cannot easily be stuck into the folder. If the integrity guarantee appears as a MAC or digital signature specific to that message, then perhaps it is reasonable for it to be printed out in the header of the message. Now to be clear, I'm not saying that TLS ought to provide this kind of functionality, nor am I even asserting that a generic layer *could* provide functionality sufficient for these sorts of apps, but I am saying that the notion of replay-prevention and integrity which is implemented in TLS is insufficient for these sorts of apps, and that I'm interested in attempts to offer a higher-level abstraction. Regards, Zooko http://zooko.com/ ^-- under re-construction: some new stuff, some broken links 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 specific way... P.P.S. A lot of the "app-specific" solutions that get deployed, such as the "add a sequence number" one mentioned in the example above, *depend* upon TLS's session-specific replay-prevention for security. Ian suggested that this was a good test of the cryptographic robustness of a higher-layer protocol. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
