[ftpext] draft-ietf-ftpext2-hash command name and default algorithm

[Robert Oslin <[e-mail]>]

draft-ietf-ftpext2-hash documents over 40 (and I'm certain this not a comprehensive list) implementations of XCRC, the non-formalized/ratified file integrity command that has been the de facto standard over the past decade. As some on this list know well, it can be extremely time consuming and costly for vendors to implement new standards in their products (I could write pages on the soup-to-nuts process involved). I believe it would make life easier on developers and speed the adoption of your RFC if you considered changing the following:



1. Keep the command XCRC vs. HASH. XCRC standards for "Transfer (xfer) Cyclical Integrity Check", not "eXperimental Cyclical Integrity Check" as some have supposed. Personally I like "HASH" better, but keeping the command the same would mean that possibly hundreds of vendors wouldn't have to change anything to start supporting it today (exception is #2 below).



2. Keep the default hash CRC32 (maybe if no opts shown in FEAT response), but recommend MD5, SHA1, or higher. Now, I understand this is a big red flag: "What about potential for collisions!" and "What about malicious users?". Yes, those are both [remote] possibilities; I grant you that. I would not advocate for CRC32 unless it were already in use by hundreds of FTP clients/servers across the world, with great success, and zero reports (that I know of) of problems. Now before you reply, consider that it would be the default, for legacy support sakes, but the RFC would strongly urge/recommend that new implementations or existing ones use SHA-1 or higher. By defaulting to CRC32 and XCRC you would avoid disenfranchising hundreds of vendors from the new standard, while encouraging new and existing vendors/developers to switch to stronger algorithms to mitigate data integrity security risks.



There is one more reason to consider using CRC32 as the default aside from grandfathering in existing XCRC vendors. CRC32 is fast! It is

2-4X faster than geekdom approved algorithms such as SHA-256. This is a big deal when it comes to FTP sessions, with the typical 30-60 second client imposed timeout between client request and server replies. According to a crypto++ API benchmark, CRC32 can process 253 MiB/Second vs. SHA-256's 111MiB/Second. That is a difference between 15 seconds for CRC32 vs. 36 seconds for SHA-256 to hash a 4 GB file (not counting disk i/o time!). Therefore you run a greater risk of timing out the socket connection when using stronger hashing algorithms.



We should also consider the problem we are trying to solve with HASH/XCRC. Are we simply trying to detect modifications due to random transmission errors, as was the original intent of XCRC? Or are we trying to detect malicious tampering or mitigate risk of collisions? If the former, then I would argue that CRC32 as the default (for legacy support and performance) is the preferred approach. If the latter, then perhaps we should enforce SHA-1 or higher as the default and force vendors to bite the bullet.



Final thoughts. Changing the command name to XCRC but not changing the default algorithm to CRC32 would make no sense. Its neither or or both. I do understand if everyone votes for a stronger (default) hashing algorithm, and I do see the benefits going forward; I just want everyone to consider the impact to existing vendors/developers and impact to performance, which could lead to more timeouts - hence failed transfers, which could adversely impact business processes.


Robert Oslin
Director of Product Management
Tel: [phone]
Fax: [phone]
Send me large files securely<https://robertoslin.cutesendit.com/>

www.globalscape.com<http://www.globalscape.com/>
[cid:image001.gif@01CBB62D.8A2A1B70]

   (NYSE Amex:GSB)<http://www.globalscape.com/cgi-bin/links.cgi?page=gsb>

*This communication, including attachments, is for the exclusive use of the addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.