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: SSL
[ Jill ] Instead, I have a different question: Where can I learn about SSL? [ Ian ] PS: next step is Ferguson Schneier's recent book which has been described as how to re-invent SSL. This reminds me: the best tutorial on the security aspects of SSL 3.0 that I know of is the Counterpane analysis paper, avaiable from: http://www.counterpane.com/ssl.html Read it to get a good idea of why certain decisions were made, and why they help. It doesn't tell you how to use OpenSSL, but it's great to let you know what's going on under the bonnet. (I kindof feel like the new Ferguson Schneier book would have been better if it had simply been this paper expanded to book length...) Cheers, William - 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: SSL
Ian Grigg [EMAIL PROTECTED] writes: Ian Grigg [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: Instead, I have a different question: Where can I learn about SSL? Most people seem to think the RFC is unreadable, so ... As in, could someone reccommend a good book, or online tutorial, or something, somewhere, that explains it all from pretty much first principles, and leaves you knowing enough at the end to be able to make sensible use of OpenSSL and similar? I don't want a For Dummies type book - as I said, I'm reasonably competent - but I would really like access to a helpful tutorial. I want to learn. So what's the best thing to go for? I am reading Eric Rescorla's book at the moment, and if you are serious about SSL, it is worth the price to get the coverage. It's well written, and relatively easy to read for a technical book. It costs a steep $50. It's not a For Dummies. You have to be comfortable with all sorts of things already. Thanks for the kind words. Actually, the price should be $40 US. That's the price at Amazon. It's giving me the intellectual capital to attack the engineering failures therein and surrounding the deployment of same. Maybe Eric will offer me $100 for my annotated copy just to shut me the f**k up ;-) I've so far discovered No payoffs, but I'd love to know what you've discovered :) -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL
Re: Eric Rescorla's SSL and TLS book: Actually, the price should be $40 US. That's the price at Amazon. Actually on bookpool.com it's $31. And if you can buy something else at the same time, they have free shipping on anything over $40. And let me 3rd or 4th the comment that it's a great book! Radia - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL
On Thu, Jul 10, 2003 at 12:04:33PM +0100, [EMAIL PROTECTED] wrote: Instead, I have a different question: Where can I learn about SSL? As in, could someone reccommend a good book, or online tutorial, or something, somewhere, that explains it all from pretty much first principles, and leaves you knowing enough at the end to be able to make sensible use of OpenSSL and similar? I'd recommend Eric Rescorla's _SSL And TLS_ book for learning about the protocol itself. It's a very good explanation of the protocol. A concise explanation of the basic protocol is in the original SSLv3 protocol spec from Netscape. It's short but must be read carefully. There's also a book on Openssl itself, that, from the parts I have looked at, seems pretty good. _Network Security with OpenSSL_ (Viega Messier Chandra). Like we've covered in this thread, Openssl has a whole lot of stuff that isn't needed for doing SSL. It's the last place you want to start trying to understand SSL. Instead, first get a basic understanding of the SSL protocol from Eric's book. Then look at Openssl. Unfortunately the simpler SSL implementations seem to not be freely available. If you do java, try Eric's 'pureTLS' java implementation. To start in Openssl, look at how the sample client and server apps work. Then step through them with a debugger. The way that Openssl is constructed with many macros and tables of pointers to functions makes it difficult to simply read until you come to recognize the names. Also, to be honest, the code is written in a style that makes it more difficult to understand than it should be. Nothing against Tim and Eric or the current Openssl crew, but anyone who uses that many single character variable names needs to be whacked on the butt with a rolled-up copy of KR C and be told NO in a very firm voice. Openssl is still changing and what little documentation they have is often stale. The openssl-users mailing list is quite active and is pretty good about answering questions. Eric - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL
On Thu, Jul 10, 2003 at 12:04:33PM +0100, [EMAIL PROTECTED] wrote: guess). However, the complexity of the OpenSSL library has me stumped. (Plus, it's Unix-centric. I'd like to turn it into a Visual Studio port so I could compile without needing cygwin, gcc, etc., but that's another story). It isn't really. I have built OpenSSL using MSVC, BC and mingw. I have a file here called openssl-0_9_7_Patch_VisualStudio6.zip culled from the OpenSSL mailing list. I haven't tried it; if you want, I can send it to you off-list. I'm not going to complain. That's been done to death here. Instead, I have a different question: Where can I learn about SSL? I always suggest learning by doing. The OpenSSL C API is quite big, but there exists wrappers in Perl, Python, Tcl, Ruby, Lisp and possibly whatever high-level language you can think of. (I have one; see .sig.) These makes programming OpenSSL more accessible. While your test programs are running, use ekr's excellent ssldump to see the stuff happening on the wire. There is also a book called SSL and TLS Essentials by Stephen Thomas that just describes the protocol. Refer to the book while you're running your programs and marveling at ssldump's output. Have fun. -- Ng Pheng Siong [EMAIL PROTECTED] http://firewall.rulemaker.net -+- Manage Your Firewall Rulebase Changes http://www.post1.com/home/ngps -+- Open Source Python Crypto SSL - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
