Re: Dutch Transport Card Broken
SSL is layered on top of TCP, and then one layers one's actual protocol on top of SSL, with the result that a transaction involves a painfully large number of round trips. Perhaps theoretically painful, but in practice this is not the case; commerce on the web is the counter-example. The benefits of layering for outweigh the perceived gains of just merging it all together into one glob. For example, the ability to replace layers, or replace them by just dropping in a new library. /r$ -- STSM, DataPower Chief Programmer WebSphere DataPower SOA Appliances http://www.ibm.com/software/integration/datapower/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
James A. Donald: SSL is layered on top of TCP, and then one layers one's actual protocol on top of SSL, with the result that a transaction involves a painfully large number of round trips. Richard Salz wrote: Perhaps theoretically painful, but in practice this is not the case; commerce on the web is the counter-example. The delay is often humanly perceptible. If humanly perceptible, too much. The benefits of layering for outweigh the perceived gains of just merging it all together into one glob. For example, the ability to replace layers, or replace them by just dropping in a new library. Compilation would provide the same benefits, and a fair bit more - such as built in protocol negotiation, rather than protocol negotiation being reinvented ad hoc in a different and incompatible way each, and bolted on after the fact in a different way each time. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Fixing SSL (was Re: Dutch Transport Card Broken)
Hi, SSL key distribution and management is horribly broken, with the result that everyone winds up using plaintext when they should not. Yes, sending client certificates in plaintext while claiming that SSL/TLS is secure doesn´t work in a world of phishing and identity theft anymore. We have the paradox situation that I have to tell people that they should use HTTPS with server-certificates and username+password inside the HTTPS session, because that´s more secure than client certificates ... Does anyone have an idea how we can fix this flaw within SSL/TLS within a reasonable timeframe, so that it can be implemented and shipped by the vendors in this century? (I don´t think that starting from scratch and replacing SSL makes much sense, since it´s just one huge flaw ...) SSL is layered on top of TCP, and then one layers one's actual protocol on top of SSL, with the result that a transaction involves a painfully large number of round trips. SSL already looks quite round-trip optimized to me (at least the key-agreement part) We really do need to reinvent and replace SSL/TCP, though doing it right is a hard problem that takes more than morning coffee. TCP could need some stronger integrity protection. 8 Bits of checksum isn´t enough in reality. (1 out of 256 broken packets gets injected into your TCP stream) Does IPv6 have a stronger TCP? As discussed earlier on this list, layering induces excessive round trips. The SSL implementations I analyzed behaved quite nicely, I didn´t noticed any round trip problems there. (But feel free to send me a traffic capture file that shows the problem) I once implemented SSL over GSM data channel (without PPP and without TCP), and discovered that SSL needs better integrity protection than raw GSM delivers. (I am quite sure that´s why people normally run PPP over GSM channels ...) SSH has the same problems. It also assumes an active attack in case of integrity problems of the lower layer, and terminates the connection. Layering communications protocols is analogous to having a high level interpreter written in a low level language. What we need instead of layering is a protocol compiler, analogous to the Microsoft IDL compiler. The Microsoft IDL compiler automatically generates a C++ interface that correctly handles run time version negotiation, which hand generated interfaces always screw up, with the result that hand generated interfaces result in forward and backward incompatibility, resulting in the infamous Microsoft DLL hell. Similarly we want a compiler that automatically generates secure message exchange and reliable transactions from unreliable packets. (And of course, run time version negotiation) Sounds like an interesting idea to me. Best regards, Philipp Gühring - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
At Wed, 30 Jan 2008 09:04:37 +1000, James A. Donald wrote: Ivan Krstic' wrote: Some number of these muppets approached me over the last couple of years offering to donate a free license for their excellent products. I used to be more polite about it, but nowadays I ask that they Google the famous Gutmann Sound Wave Therapy[0] and mail me afterwards. Gutmann Sound Wave Therapy: Gutmann recommends: : : Whenever someone thinks that they can replace : : SSL/SSH with something much better that they : : designed this morning over coffee, their : : computer speakers should generate some sort : : of penis-shaped sound wave and plunge it : : repeatedly into their skulls until they : : achieve enlightenment. On SSL, Gutmann is half wrong: SSL key distribution and management is horribly broken, with the result that everyone winds up using plaintext when they should not. SSL is layered on top of TCP, and then one layers one's actual protocol on top of SSL, with the result that a transaction involves a painfully large number of round trips. We really do need to reinvent and replace SSL/TCP, though doing it right is a hard problem that takes more than morning coffee. I can't believe I'm getting into this with James. Ignoring the technical question of broken, I know of no evidence whatsoever that round trip latency is in any way a limiting factor for people to use SSL/TLS. I've heard of people resisting using SSL for performance concerns, but they're almost always about the RSA operation on the server (and hence the cost of server hardware). If you have some evidence I'd be interested in hearing it. -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
Why require contactless in the first place? Is swiping one's card, credit-card style too difficult for the average user? I'm thinking two parallel copper traces on the card could be used to power it for the duration of the swipe, with power provided by the reader. Why, in a billion-dollar project, one must use COTS RFIDs - with their attendant privacy and security problems - is beyond me. A little ingenuity would have gone a long way. OPs deliberately elided. This posting (and several others in this thread) disturb me. Folks on this list and its progenitors have long noted that cryptography is a matter of economics. That is, cryptography and security aren't absolute goals; rather, they're tools for achieving something else. The obvious answers in this case are prevent fare fraud or make money, and even those would suffice. However, there are other issues less easily monetized, such as make the trams and buses run efficiently. A security system doesn't have to be perfect. Rather, it has to be good enough that you save more than you lose via the holes, including the holes you know about up front. Spending more than you have to is simply bad engineering. Speaking as an engineer, rather than as a scientist, the real failure mode is too high a net loss. As a cryptographer and security guy, I'd rather there were no loss -- but that's not real. A transit system has to move people. For all that the New York City Metrocard works, it's slower than a contactless wireless system. How much longer will it take people to board trams with a stripe reader than with a contactless smart card? What is your power budget (which affects range)? Even leaving out the effect that delays have on ridership, a transit system that wants to move N people needs more units if the latency per rider is above a certain threshold. Let's take a closer look at the New York system, since it was touted as superior. It's optimized for subways, not buses, which has several implications. (Subway ridership in New York is twice bus ridership -- see http://www.crainsnewyork.com/apps/pbcs.dll/article?AID=/20070223/FREE/70223008/1066) First, subway turnstiles are much more easily used as part of an online system than are bus fare card readers. The deployment started in 1994, when cellular data simply wasn't an option, based on cost, bandwidth, availability, and much more. Second, on a subway you use your fare card well in advance of boarding; there is thus little latency effect on the system. Third, wireless is *still* faster -- according to some reports (http://www.dslreports.com/forum/r19222677-The-Next-MetroCard), the MTA is considering replacing the current system with a wireless one. Online systems have another issue: they require constant communication to a high-availability server. When that's not an option (i.e., New York buses, or subway turnstiles when the server is down), the system has to fall back to some other scheme. This scheme is more restrictive, precisely because of the fraud issue. Back when I was in high school, some students got bus passes. I recall a frequent sight: those who had boarded early moving to the back of the bus and handing their passes to other students still waiting to board the bus. Replay worked well against an overloaded driver... Metrocards don't have that failure mode -- but the failure mode they do have is a limitation on how many times they can be used in a short time interval. This affects, for example, a family of five or more trying to travel on a single card, even on subways. How much of this applies to the Dutch farecards? I have no idea. But this group is trying to *engineer* a system without looking at costs and other constraints. That leads to security by checklist, an all-too-common failing. Systems like this have two primary failure modes -- failure in the sense of losing more money (or time, or what have you) than anticipated. First, the designers may not have understood the available technology and its limitations. That was certainly the case with WEP; I suspect it's the case here, but I don't know. Even so, it is far from clear that exploitation of the hole will have an economic impact; that's as much a sociological question as a technical one. (Maybe the incremental cost per card of better crypto is ?.01. One web site I found put tram ridership in Amsterdam at 1,000,000/year (http://blog.wired.com/cars/2007/10/trams-dominate-.html), which means that the cost might be ?10,000/year. How many riders will try to cheat the system? Enough that to be an issue? I don't know -- but that's precisely my point; I don't know and I doubt very much that most other posters here know. That said, I do suspect that stronger crypto would be economical.) The second failure mode comes from misunderstanding the threat model. That's why the old American AMPS cellular phones were subject to cloning attacks. It was *not* that the designers didn't anticipate
RE: Dutch Transport Card Broken
James A. Donald: SSL is layered on top of TCP, and then one layers one's actual protocol on top of SSL, with the result that a transaction involves a painfully large number of round trips. Richard Salz wrote: Perhaps theoretically painful, but in practice this is not the case; commerce on the web is the counter-example. James A. Donald: The delay is often humanly perceptible. If humanly perceptible, too much. I respectfully disagree - I'd argue that a short wait is actually more reassuring to the average user (Hey! The System's checking me out!) than an instantaneous connection would be. Adding in a false wait (a nice pop-up, a progress bar and a snake-oily security message) would be even better... Regards, Jim Cheesman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
James A. Donald [EMAIL PROTECTED] writes: James A. Donald: SSL is layered on top of TCP, and then one layers one's actual protocol on top of SSL, with the result that a transaction involves a painfully large number of round trips. Richard Salz wrote: Perhaps theoretically painful, but in practice this is not the case; commerce on the web is the counter-example. The delay is often humanly perceptible. If humanly perceptible, too much. The initial delay in connecting is usually DNS related, not SSL related, and is often experienced even in ordinary http: web surfing. I don't think that the delays involved in the SSL handshake are particularly perceptible amidst the other delays involved in connection setup, unless you're on a very high delay network like one of the older cellular data systems that are now going away anyway. Protocol hacks also make subsequent connections to the same server quite fast. In any case, although SSL has some compromises in the design, it is pretty good overall, and I can't see a good reason why one would pick something else in almost any ordinary situation. A real expert might find corner cases where it is not suitable, but there are very few experts out there, though lots of people who incorrectly think they are. I've seen idiots produce many things that were slower and had horrible security properties, all the while costing far more in software development, because they thought they knew better -- I've never seen anyone actually do better, though. For practical purposes, the rule is don't use something else, and if you think you're smart enough to do better, you almost certainly aren't. (No, I'm not a fan of X.509 certs, but those are not core to the protocol, and you can think of them as nothing more than a fancy key container format if you like. Key management is not addressed by SSL, so there is no reason that fixing key management has anything to do with SSL per se.) I'm sure you're going to disagree with me, James, but I won't be responding -- I don't think you're right, but I also see no reason to beat a dead horse. My opinion (and just about everyone else's) is well known. We live in a world where you are free to have a dissenting view. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
I don't disagree with your posting in general. I will note one thing: Steven M. Bellovin [EMAIL PROTECTED] writes: A transit system has to move people. For all that the New York City Metrocard works, it's slower than a contactless wireless system. As a consultant, I happen to have a lot of ID badges. I've used contactless systems for entry at several firms on a regular basis. I've experienced the equivalent of re-swipe problems even with the contactless systems -- that is, I've been forced to wave the card past the reader more than once. I'm told that similar issues can be found in other RFID systems. Although I will not disagree that the only important criterion for a transit system is will we maximize overall economic efficiency with this design choice, I'm still far from certain that contactless is always going to be faster. It could in theory be faster -- whether that theory can be reduced to practice is a different question. (As an aside, I'll also point out that, in the NYC transit system, it is fairly rare that the rate limiting step is the speed of turnstile reads. Far more often, limited space on stairwells, limited numbers of turnstiles (which are used both for entry and exit), etc., seem to be the limiting factor on how fast people can flow onto and off of the platforms.) I want repeat that I don't disagree with you that all of this is about economics first, and the security level and costs have to take that into consideration. We are in violent agreement there. A $100 but perfect entry token is going to be worthless for most transit systems, and an attack that costs a system a few dollars a year at most is unlikely to be worth closing. (Indeed, the Metrocard system isn't perfect, in that you can clone cards -- you just can't steal more than a trivial sum before the card will be turned off, so no one bothers.) My main point here was, in fact, quite related to yours, and one that we make over and over again -- innovation in such systems for its own sake is also not economically efficient or engineering smart. If an existing system works reasonably well and you can use it off the shelf without paying development and other costs, why not use it? I find the fact that nearly every city in the world seems to have a custom designed electronic fare system somewhat peculiar -- I'm not surprised that several such systems might exist, but surely every city in the world does not need to sink the costs of custom development of an entire fare system. The Dutch apparently sunk vast sums into the development of a brand new fare card system -- one questions what requirements could not have been met with one of the several hundred existing systems. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [tahoe-dev] Surely M$ can patent this process?
On Jan 27, 2008 11:18 AM, zooko [EMAIL PROTECTED] wrote: [adding Cc: p2p-hackers and cryptography mailing lists as explained below; Please trim your follow-ups as appropriate.] On Jan 26, 2008, at 9:44 PM, Gary Sumner wrote: Surely there must be prior art on this technique to refute this patent? That's an interesting question, and I'm carbon-copying the p2p- hackers and cryptography mailing lists to ask if anyone knows. FYI: http://www.opencm.org/papers/cpcms2001.pdf CPCMS: A Configuration Management System Based on Cryptographic Names. Jonathan S. Shapiro, John Vanderburgh, Systems Research Laboratory, Johns Hopkins University. Appeared in the 2002 USENIX Annual Technical Conference -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Dutch Transport Card Broken
Folks on this list and its progenitors have long noted that cryptography is a matter of economics. Agreed, but using an insecure technology doesn't make sense from even an economic perspective. They spent enough money that they could have implemented a secure system, but instead, made two fundamental errors: 1.) The cost of fraud is probably much less than the cost of the system - 2 billion. So, even if the system were completely secure, they still might have been better off using paper tickets and the honor system. From all indications, there were no cost controls on this project, so it seems likely that the technology was not chosen because of technical reasons or economic reasons, but rather, because someone was familiar with it. Perhaps it was suggested by a politician, and his cronies made it their mission to make it happen. Perhaps someone thought that it would impress visitors; maybe it was a matter of national pride. 2.) The implementation was insecure. Yes, there were probably technical factors involved, but for the cost of the project, they could have implemented a secure system, using other means if necessary. The problem, as I see it, was not an economic one, but rather, that the developers relied on the secrecy of the algorithm for security, rather than the size of the key. Even unpaid, open-source developers have produced secure systems for far less than the Dutch spent simply because they followed good cryptographic design guidelines. The question about mag strip versus RFID versus physical-contact readers is a valid one. For 2 billion, the cost/convenience difference between radio and contact cards would have to be rather large to justify implementing an insecure system. Even a swipe time of 100 ms is enough to implement a secure solution. I find it very unlikely that a competent engineering firm could not implement this in a reliable, secure, and fast manner given this project's budget. If the assertions are correct - that the subway is used 1,000,000 times (or by 1,000,000 people?) a year, spending 2 billion on the fare system means approximately 2,000 per user/time. For those math types, that's ~~5.50 per day just to pay for the fare system, not to mention the cost of electricity, trains, maintenance, etc... How many people spend more than 5.50 per day on train/subway/bus fare? This system, and its attendant costs - though obsolete even before its inception - will probably be amortized over a few decades. Which is why fraud is a very important issue. In that time frame, it is very likely that the criminal underground could produce, and profit from, counterfeit cards on a large scale. Unlike turnstyle jumpers, fraud of this kind could easily become so widespread that the subway system operates at a significant loss. A turnstyle jumper is easily caught; a rider with a cloned card is virtually undetectable (without expensive upgrades to the system). If this system had been securely implemented, we might be able to know if the fraud prevention would ever have exceeded the 2 billion cost of the system; but because it isn't, the Dutch have essentially flushed the money into the sewer. And, bringing economics back into the picture, the purpose of the Mifare system is *to prevent fraud*. I seriously doubt that such a system - especially now that it is broken - will eliminate 2 billion worth of fraud. It seems the Dutch would have been better off simply issuing paper tickets and relying on the honor system. Most people are honest; the purpose of the ticket system is to keep people that way. Unfortunately, it fails from both perspectives: it isn't economically viable, and neither is it secure. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: two-person login?
On Tue, 29 Jan 2008, John Denker wrote: The foregoing makes sense, and is in extreme contrast to the situation I am faced with, where Joe logs in with the help of Jane, and then Jane leaves. Jane has not the slightest control over what Joe does while logged in. I don't see a sane procedure here. It seems Jane is signing a blank check. Ah. Jane need not have a requirement to know what Joe is doing; in fact, Jane may not even be cleared for Joe's material. (This is not uncommon. Jane may be security officer, Joe may be payroll manager. Jane is not authorized to see payroll data or even use the payroll joe account.) What has transpired is that Joe cannot deny that he was logged on. He can further deny that other logins that he did not perform were done by him, assuming Jane is honest. Jane can attest that the login by user joe was done by human Joe. It wouldn't be so bad if there were a development system separate from the production system, but there isn't, so Joe spends all day every day logged into the high security production system. Joe can commit anything he wishes. There is no two-party review of the commit, just two-party review of the login. Correct. Logins by Joe-impersonators, even those who have stolen Joe's password, say, are impossible without Jane's collusion. Just to rub salt in the wound, they've got it set up so that everybody uses the Admin account. There are N people who know the first half of the Admin password, and M people who know the second half. Besides being an incredibly lame form of secret-splitting, this has the nasty property that when Admin logs in, you don't even know who was involved. There are M*N/2 possibilities. There is no accountability anywhere. This is sounding something like the FBI's method for getting at certain sensitive info, that was recently subjected to criticism. There was only one account to access the data, all operatives had the password. Adding Jane sounds like an inept fix. Dave - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Philipp Gühring wrote: Yes, sending client certificates in plaintext while claiming that SSL/TLS is secure doesn´t work in a world of phishing and identity theft anymore. We have the paradox situation that I have to tell people that they should use HTTPS with server-certificates and username+password inside the HTTPS session, because that´s more secure than client certificates ... Does anyone have an idea how we can fix this flaw within SSL/TLS within a reasonable timeframe, so that it can be implemented and shipped by the vendors in this century? (I don´t think that starting from scratch and replacing SSL makes much sense, since it´s just one huge flaw ...) re: http://www.garlic.com/~lynn/aadsm28.htm#15 Dutch Transport Card Broken http://www.garlic.com/~lynn/aadsm28.htm#16 Dutch Transport Card Broken aka ... that was part of the relying-party-only certificates from the mid-90s; http://www.garlic.com/~lynn/subpubkey.html#rpo i.e. the x.509 identity digital certificates from the early 90s, were becoming more and more overloaded with personal information ... and by the mid-90s, lots of institutions were starting to realize all that personal information represented significant privacy and liability issues ... and the RPO digital certificates were born. However, it was trivial to demonstrate that (for all those business processes) that the digital certificates were redundant and superfluous (however, there was some amount of industry brain washing that digital certificates were mandatory ... especially if digital signatures was used ... even if they served no useful purpose). this also showed up in work on pk-init for kerberos supporting digital signature authentication ... and got into the confused mess with redundant and superfluous digital certificates http://www.garlic.com/~lynn/subpubkey.html#kerberos and similarly digital signatures for radius http://www.garlic.com/~lynn/subpubkey.html#radius (between kerberos and radius, they represent possibly the majority of authentication in the world today) part of the confusion regarding the necessity for digital certificates could be seen in the X9F financial standards work ... the appending of even a relying-party-only digital certificate (lacking any personal information) could represent a factor of 100 times payload bloat http://www.garlic.com/~lynn/subpubkey.html#bloat for a nominal electronic payment transactions (and also 100 times processing bloat). as a result, there was some standardization effort looking at compressed (relying party only) digital certificates (even tho they were serving no useful purpose), attempting to get the payload bloat down to possibly only 5-10 times (instead of 100 times). I took the opportunity to demonstrate that it would be logically possible to compress such digital certificates to zero bytes ... totally eliminating the payload bloat. then rather than advocating the elimination of totally useless, redundant and superfluous digital certificates http://www.garlic.com/~lynn/subpubkey.html#certless there could be an infrastructure that mandated zero-byte digital certificates appended to every transaction. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
At Wed, 30 Jan 2008 17:59:51 -, Dave Korn wrote: On 30 January 2008 17:03, Eric Rescorla wrote: We really do need to reinvent and replace SSL/TCP, though doing it right is a hard problem that takes more than morning coffee. TCP could need some stronger integrity protection. 8 Bits of checksum isn´t enough in reality. (1 out of 256 broken packets gets injected into your TCP stream) Does IPv6 have a stronger TCP? Whether this is true or not depends critically on the base rate of errors in packets delivered to TCP by the IP layer, since the rate of errors delivered to SSL is 1/256th of those delivered to the TCP layer. Out of curiosity, what kind of TCP are you guys using that has 8-bit checksums? You're right. It's 16 bit, isn't it. I plead it being early in the morning. I think my point now applies even moreso :) Since link layer checksums are very common, as a practical matter errored packets getting delivered to protocols above TCP is quite rare. Is it not also worth mentioning that TCP has some added degree of protection in that if the ACK sequence num isn't right, the packet is likely to be dropped (or just break the stream altogether by desynchronising the seqnums)? Right, so this now depends on the error model... -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Dutch Transport Card Broken
On 30 January 2008 17:01, Jim Cheesman wrote: James A. Donald: SSL is layered on top of TCP, and then one layers one's actual protocol on top of SSL, with the result that a transaction involves a painfully large number of round trips. Richard Salz wrote: Perhaps theoretically painful, but in practice this is not the case; commerce on the web is the counter-example. James A. Donald: The delay is often humanly perceptible. If humanly perceptible, too much. I respectfully disagree - I'd argue that a short wait is actually more reassuring to the average user (Hey! The System's checking me out!) than an instantaneous connection would be. I also disagree. It's not like anyone says to themselves Hey, this website is taking me several seconds to access - I'll spend a couple of hours physically going to the shop instead. It's economics again: what amount of time or money constitutes too much depends what the alternative choices are. cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Dutch Transport Card Broken
On 30 January 2008 17:03, Perry E. Metzger wrote: My main point here was, in fact, quite related to yours, and one that we make over and over again -- innovation in such systems for its own sake is also not economically efficient or engineering smart. Hear hear! This maxim should be burned into the frontal lobes of every single member of Microsoft's engineering (and marketing) teams with a red-hot poker[*]. [ Over-engineered solutions to non-problems and gratuitous marketing-driven featuritis have been the root cause of almost every windows security disaster ever - e.g., email featuring 'rich content' such as scripts; web browsers that download and locally run active-x from random websites; lots of vulnerable RPC services installed and enabled by default on home user PCs; ... etc etc.; certainly they have far outnumbered the occasional flaws in core kernel services. But - economics again!, and a tip'o the hat to Schneier and his externalities argument - as long as the extra sales go to Microsoft's coffers, and the extra costs are all imposed on their victims^Wusers, there's no incentive for them to do otherwise. Hence my suggestion that they need a red-hot one (incentive, that is). ] cheers, DaveK [*] - or red-hot Gutmann soundwave -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Fixing SSL (was Re: Dutch Transport Card Broken)
On 30 January 2008 17:03, Eric Rescorla wrote: We really do need to reinvent and replace SSL/TCP, though doing it right is a hard problem that takes more than morning coffee. TCP could need some stronger integrity protection. 8 Bits of checksum isn´t enough in reality. (1 out of 256 broken packets gets injected into your TCP stream) Does IPv6 have a stronger TCP? Whether this is true or not depends critically on the base rate of errors in packets delivered to TCP by the IP layer, since the rate of errors delivered to SSL is 1/256th of those delivered to the TCP layer. Out of curiosity, what kind of TCP are you guys using that has 8-bit checksums? Since link layer checksums are very common, as a practical matter errored packets getting delivered to protocols above TCP is quite rare. Is it not also worth mentioning that TCP has some added degree of protection in that if the ACK sequence num isn't right, the packet is likely to be dropped (or just break the stream altogether by desynchronising the seqnums)? cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
