Re: replay & integrity
On Wednesday, Jul 9, 2003, at 13:31 US/Eastern, Whyte, William wrote: 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. This would be a side-channel problem in the protocol which needs to be fixed, not obfuscated by an integrity mechanism. Worse, the integrity protection didn't even work in TLS 1.0: "TLS v1.0 also provides an optional MAC which failed to thwart the attack..." [Vau02a]. [Vau02a] http://lasecwww.epfl.ch/php_code/publications/search.php?ref=Vau02a -J -- Jeroen C. van Gelderen - [EMAIL PROTECTED] "Be precise in the use of words and expect precision from others" -- Pierre Abelard - 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]
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
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: "100876975231 USD1000.00". 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 "completed", 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
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: "100876975231 USD1000.00". 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 "completed", 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
> 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]
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
> 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]
New algorithms and protocols, etc. (was Re: replay & integrity)
Ian Grigg <[EMAIL PROTECTED]> writes: > Eric Rescorla wrote: > > 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 [more examples of protocols that have their own replay, integrity, etc. protection elided.] > 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 This is the security world. We survive because of making cautious assumptions. Adding anti-replay and integrity to your protocol is cheap, and once you've done it and analyzed it well, you have a solid component on which to build. Rolling your own non-protected protocol that has not been analyzed because you think that you don't need the feature buys you essentially nothing at all and endangers you. There is nothing wrong with several layers in your communication system all doing similar kinds of protection. It is fine that you're sending S/MIME signed and encrypted messages over TLSified SMTP. The cost is merely speed, and since hardware is used for most of the instances where speed is a problem, it isn't an issue at all for the most part. Besides, you often find you've gained something by providing the redundant protections. The truth is that people don't propose new algorithms and protocols because there is a great unmet need they are trying to fill or because a tiny bit of speed is lost through redundant safety measures. If they aren't snake oil peddlers (a large category, sadly) they propose them because they haven't read the literature and/or they enjoy tinkering. Now, tinkering is a fine and wonderful thing, and I'm a big advocate of tinkering. It is fun building things, and the pleasure of doing so is its own reward. It is also very educational. Just because you like building your own cars from scratch, though, doesn't mean that they're safe for the general public to drive, or that they'd be in any way cheaper or better than cars built by professionals. Likely what you build will be a clunker and have no advantages, and be unsafe besides. Even if you had some slight advantages, the mere fact that your parts are non-standard will make it impossible for others to analyze or maintain your car design. The same is true in cryptography and security. Of course, this makes the world kind of boring and unpleasant for tinkerers who want to go pro. The most obvious cryptographic algorithm needs and cryptographic protocol needs have been essentially filled already -- AES, RSA, TLS and other components are all just fine and more or less span the whole space of requirements. All that is left is the comparative drudgery of implementing well known protocols and (since most of them have been implemented) using them. No fun at all! This is not to say that we don't need people inventing new algorithms and protocols, because we do -- in an academic context. After all, someday AES will seem too weak, or someone will find a yet cleverer way to factor large composites, and besides, we still don't have ideal protocols for many sorts of distributed problems. Furthermore as I said, there is nothing wrong with good clean fun. What we don't need is people mistaking the sort of play and research of academia for things that should be released as software to the public. The shame of it all is, as people have noted, there is substantial demand for better implementations of things like SSL, and even more importantly, for better applications and infrastructures. It is too hard to use the tools we have now, but not because AES is somehow hard to use or because SSL is a bad component. The problems we have deploying, both because of things that are difficult for programmers to use and because of things that are inconvenient for users, are a massive problem, and one that cries out for lots of work. Unfortunately, it is the sort of work that isn't glamorous. In engineering, one often finds a distinction between the personalities of innovators and "finishers" -- the guy who's great at coming up with a new car engine idea vs. the guy who's really good at cleaning up the new engine idea for manufacturability and simplicity but who would not have thought of the idea in the first place. It is t
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]