Re: replay integrity
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: transferoutaccount_id100876/oinaccount_id975231/i currencyUSD/camount1000.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_statuscompleted/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]
Re: replay integrity
Zooko, I don't think you actually need to worry about the At-Most-Once semantics you example below. This sort of stuff has been around for decades and there are a number of open source programs available. Don't confuse what TLS does - transport messages securely end-to-end - to what the end points do with them. We don't need to have another protocol which includes TLS+At-Most-Once semantics. I'd say that would be a terrible idea. Chuck Wegrzyn 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 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: transferoutaccount_id100876/oinaccount_id975231/i currencyUSD/camount1000.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_statuscompleted/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.
Re: replay integrity
At 02:19 PM 7/9/2003 -0400, Zooko wrote: 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.) we did two kinds of replay countermeasures ... one for AADS RADIUS http://www.garlic.com/~lynn/subpubkey.html#radius http://www.asuretee.com/ and a different kinds for x9.59 (for all electronic payments in all environments) http://www.garlic.com/~lynn/index.html#x959 in the aads radius there is this (real-time) protocol chatter; client contacts server, server returns message with unique value, client includes unique value in signed message that is returned to server. server validates the signature and makes sure the client's message returns the previously transmitted unique value. for x9.59 to work in all environments ... it had to operate in single round trip (as per many of existing financial messages). the client creates a complete signed message and sends it to the server (financial institution), the message has some possibly unique values ... but not necessarily guaranteed, including time. the server uses current time and message time to bracket checking of previously processed messages for replay. the radius implementation requires two round-trips to establish the unique value as part of replay counter measure. the x9.59 implementation (in order to meet one of the requirements for the protocol; perform completely in single round trip) uses a log and a sort of fuzzy time implementation (at the server). this is in part because the client end can be considered somewhat unreliable ... not necessarily being able to reliably remember previous value and/or keep synchronized time. highly synchronized time could eliminate the log check. having reliable client that was guaranteed to remember previous transaction could get by with the log elimination by using a take off on the single password scheme where both the server and the client reliably remembers just the previously used value, this rmemory doesn't get out of sync ... and the iteration to the next value is non-obvious. and of course the overall requirement given the x9a10 working group for x9.59 was to preserve the integrity of the financial infrastructure for all electronic payments in all environments. -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: replay integrity
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 itself.) [...] 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 specific way... 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]
replay integrity
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]
RE: replay integrity
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. [ ... ] 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. Maybe so, but if you don't have integrity checking, so that an attacker can inject packets into the stream, this can often compromise privacy too. For example, consider Serge Vaudenay's CBC padding attack. Cheers, William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: replay integrity
tom st denis [EMAIL PROTECTED] writes: --- Eric Rescorla [EMAIL PROTECTED] wrote: This is all fine, but irrelevant to my point, which is that if you're designing a channel security protocol it should provide channel level integrity and anti-replay unless there's some really good reason not to. For the love of god the horse is dead. Let it be! I've pulled the code [and the rest of the site]. I admitted you were right, I admited it had unintentional flaws. What more do you want? Tom, I'm sorry you're taking this personally, since it's not really about you. I take Ian to be making a generic argument that there's not a need for these features in a channel security protocol. I've certainly hear this argument before and I think it's worth discussing--even though I think he's wrong. -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: replay integrity
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]
