| To: | cipe-l,AT,inka,DOT,de |
| Subject: | Long message - thoughts on Gutmann response |
| From: | "R. Steve McKown" <rsmckown,AT,yahoo,DOT,com> |
| Date: | Wed, 24 Sep 2003 12:59:44 -0600 |
Hi, As a fan and user of CIPE, and as owner of a small company that helps customers use CIPE to secure traffic between physical locations, I'm pretty concerned over the ramification of Gutmann's response. I've now had two customers query me about this message. The general response after the first read seems to be: "this guy is an expert, CIPE has problems, it's better to be safe than sorry, so maybe we should look for something else". However, after reading carefully and listening to others on this list, I feel that are a number of problems with this analysis, and that it leads to inaccurate conclusions by the reader. I present these thoughts to the list in hopes that they might be useful in helping craft an "official" CIPE response. Please note that I am definitely *not* a crypto expert, and so my comments may present wrong facts or make wrong assessments. If this info is more pain then help, please hit delete in your e-mail as fast as you can! Gutmann claims his analysis is "evolving" (his word). Here's the link on his site: http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt. CIPE usage ----------------- "A friend of mine recently pointed me at CIPE, a Linux VPN tool that he claimed was widely used but that no-one else I know seems to have heard of." Why is this comment so important as to be the first statement and introduction for his analysis? I am also concerned that he only took a "quick look" while at a friend's place. Gutmann is apparently a strong crypto guy, so his quick look probably beats most's comprehensive analysis. But there is other evidence in his document to suggest his look may have been perhaps too cursory or performed from a predisposed viewpoint that undermines an unbiased analysis. CIPE uses a compromisable CRC-32 checksum ----------------- CIPE is using the checksum to validate proper delivery of an encrypted packet; i.e. identify packets corrupted during transit. While Gutmann's references are correct, he muddies the water a bit. Yes, the CRC-32 has a known attack and its use in CIPE is apparently a weakness. But this weakness alone does not provide an exploit make. Gutmann then goes on to highlight how such a weakness played a *part* in an SSHv1 exploit. Comparing a weakness in one product to an actual exploit in another is circumstantial and sensational. CIPE uses a too-short padding length ----------------- This is a valid weakness. This issue in and of itself does not provide an exploit, but in conjunction with others it might. Nothing in Gutmann's analysis shows valid evidence of an imminent threat. CIPE has no replay protection ----------------- CIPE is stateless and doesn't provide replay protection; it relies on upper layers in the protocol stack to do so. TCP, for example, provides the necessary mechanics to impart pretty decent (in my opinion) replay protection. Non-TCP apps almost always implement message reliability in their internal protocols, which also impart replay protection. By being stateless, CIPE is less complex and doesn't incur the overhead of replay protection when it is usually provided elsewhere. It is unclear to me whether my understanding is wrong, Gutmann didn't understand this decision, or if he discounted the approach so dramatically it wasn't even worth mentioning. Assuming I'm accurate thus far, the glaring error in Gutmann's analysis is his example which infers that one could replay a database transaction through a CIPE tunnel. Database systems invariably provide message reliability mechanisms *and* are usually implemented on top of TCP. Gutmann's claim seems disingenuous, since there appears no way for it to be valid. CIPE keys can be modified in transit ----------------- Gutmann uses the example of 3DES and how a bit-flipping technique used in conjunction with CRC-32 checksums might be used to alter key values. He then indicates that IDEA has weak keys like 3DES and infers that it would also be vulnerable. This inference is not compelling evidence, but perhaps with Gutmann's knowledge base the inference is clear. But this whole section is moot, because every implementation of CIPE I've seen uses the far superior Blowfish algorithm, which he doesn't address at all. The source document Gutmann uses to analyze CIPE is clear in the use of this algorithm, so I'm unsure of the rationalization of not addressing it at all. Because Gutmann does not show the above key attack is effective in CIPE, the rest of his points in Section 3 are not supported. However, I'm compelled to point out his analysis of keyex management packets. He implies that the CRC-32 attack (in conjunction with others) can be used on these packets. This is true, because applying an attack does not imply success (although a reader may infer such). By his own analysis, it doesn't appear one will have the minimum of 16 bytes of known plaintext, as the flag in question appears to be part of a 4-byte bit field (perhaps encapsulated IP header info?). Further, he did not address the exposure of the Blowfish cipher to the key bit-flip attack. Using his data, he hasn't convinced me this attack is possible. At Gutmann's apparent level of crypto experience, I have to either conclude that he isn't good at presenting all the facts, I'm missing some obvious information unsaid in the article, or he misleads the reader in his analysis of keyex packet vulnerability. Thoughts - insecure security products ----------------- "At least Microsoft eventually tries to fix their stuff, given sufficient public embarrassment and the odd hundred thousand or so computers being taken out by attackers." How is this comparison valid? CIPE has no reported systems or data compromises. The Microsoft product in question has had several. Gutmann is comparing the unrealized *possibility* of an exploit with the *reality* of multiple exploits. Rather than support his message that many open source developers don't have the skill or interest to maintain the security level of their products, his comparison does a better job of supporting the converse. Summary of Analysis ----------------- This quote from the analysis summarizes what I feel to be Gutmann's personal perspective before, during, and after writing this analysis: "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." I come to the conclusion that this analysis is more a rant. One by a gifted and talented individual and one that does make some valid points, but a rant nonetheless. Effective analyses don't typically rely on circumstantial evidence, unsupported inference, disingenuous facts, omission of relevant data, and faulty conclusions. After initial research and review, I find this analysis to be much thinner on substantive claims that I originally anticipated. Benefits of CIPE ----------------- Most professional analyses I read tend to state both strengths and weaknesses, then provide insight into which contextual uses of the analyzed product may pose problems or issues. Gutmann doesn't do this, so let me try. 1. CIPE is small and therefore easily audited and maintained. CIPE has ~ 7.954 lines of code. FreeS/WAN has ~ 96.265 and openssh/openssl combine for ~ 281,431. Complexity and defect count are proportional. Defects often can be used to subvert security. All else being equal, CIPE will be far more secure. 2. CIPE has had no reported exploits, yet has been around and in use for years. Compare that to the track record of those products Gutmann feels more comfortable with, like ssh and ssl. 3. Gutmann used 3DES and IDEA in his analysis, but don't most of us use the Blowfish cipher? Anyway, it appears that key weakness in IDEA (and apparently to a lesser extent Blowfish) is exploitable only under very limited and typically unlikely situations: http://gunther.smeal.psu.edu/context/136432/0 4. CIPE uses preshared keys. As long as the key transfer is done over a secure medium, CIPE avoids all the complexity of PKI (and the inherent defects in that much code) without incurring a decrease in security. (We don't use pkcipe). 5. CIPE rekeys regularly. Gutmann doesn't address this, probably because it seems to be a given feature. But doesn't this limit a "crack" to the duration a given key is in play? 6. CIPE is not as heavily used as other protocols. This makes it a less enticing target. While this is not a sound reasoning for selecting a security technology, it has a valid impact on the exposure and risk equations. Concerns with CIPE ----------------- 1. CRC-32 is a valid weakness in CIPE. Real exposure level? unknown 2. Packet padding is a valid weakness in CIPE. Real exposure level? unknown 3. CIPE uses the Blowfish cipher (does anyone still use IDEA?). If Blowfish is ever compromised, it will take more time to modify CIPE to switch to a different, presumably more secure cipher. 4. CIPE is not as heavily used as other protocols. This makes it a less enticing target, but also means it may not be subjected to the same scrutiny by the white and black hat communities as the other products. This is a corollary to "security by obscurity", which has been proven invalid in the past. The Future of CIPE ----------------- I understand CIPE's next major release will use the linux in-kernel cryptoapi system, which will allow runtime selection between multiple high-end ciphers, like Blowfish, 3DES, and AES. Perhaps other valid issues Gutmann has raised will also be addressed? I like the architecture of CIPE. A simple encrypting tunnel based on sound security underpinnings is much more valuable to me and those I support than a feature-laden, complex technology that is more likely to contain errors and be exploited. All the best, Steve McKown Titanium Mirror, Inc.