HASH: Transfer Integrity command

Hi,

I'm working on an Internet Draft (RFC in progress) to create a new FTP command to be used by clients to request cryptographic hashes of files. A number of vendors & applications plan to support it.

From what I've seen, this software supports the non-standard XMD5, XSHA1, XSHA256, XSHA512 commands.

I'm soliciting comments and suggestions on the Internet Draft text. Your feedback is most welcome!

http://tools.ietf.org/html/draft-bryan-ftp-hash


Here's how it works:

[indent]Example of HASH client request:

HASH filename.ext

HASH server response with Positive Completion code and the requested
hash using the currently selected algorithm:

213 80bc95fd391772fa61c91ed68567f0980bb45fd9[/indent]


OPTS is used to query or change the algorithm:

[indent]C> OPTS HASH
S> 200 SHA-1
C> OPTS HASH SHA-512
S> 200 SHA-512
C> OPTS HASH CRC-37
S> 501 Unknown algorithm, current selection not changed[/indent]


Support is advertised in FEAT responses:

[indent]C> feat
S> 211-Extensions supported:
S> ...
S> HASH SHA-1*;MD5
S> ...
S> 211 END[/indent]

* You may want add a reference to the CKSM command which is surprisingly missing in the draft and has very similar functionality:
http://www.ogf.org/documents/GFD.47.pdf
CKSM is supported by SmartFTP.

* I think the reference to the "Hash Function Textual Names" registry should be included:
http://www.iana.org/assignments/hash-fu ... ext-names/

* I have noticed that the partial hashes are in the todo list. I actually think it should be mandatory to specify the offset and size to avoid any race conditions that might occur. E.g. 2 clients. One uploads the file, the other issues a HASH command. What will the hash command return? Most likely not what the client expects. In conclusion my recommendation is:

HASH <algorithm> <offset> <length> <path> CRLF

or to better fit it into your OPTS mechanism:

HASH <offset> <length> <path> CRLF

Is there already a server implementation available for testing?

Is there already a server implementation available for testing?

no implementations at all so far, but the FileZilla author is a co-author of the draft so that will be one of the first. IIS is also interested. we have only been getting feedback for a few weeks & have changed things once, so things may not be stable enough.

thanks for the comments!

in your experience, how useful/needed are partial hashes?

PS - you may also be interested in the HOST command ID, which is in Last Call: http://tools.ietf.org/html/draft-hethmo ... -ftp-hosts

>Filezilla
The server part of Filezilla looks abandoned. And for the client, in this case I guess we are the first that implemented it

>partial hashes
They are a must due to the reason explained in my last reply (multi part transfers and race condition).

>HOST
Thank you. It has already been implemented in our application a while ago. Unfortunately there are some problems the authors of the draft didn't take into consideration.

Thank you for sharing. I have successfully tested the latest version of SmartFTP with the FileZilla server.

awesome!

btw, there is a new IETF FTP email list https://www.ietf.org/mailman/listinfo/ftpext
it will be very low traffic. if you're interested, you could just post a message on there introducing yourself, it'd be great.

do you think there are any FTP extensions that should be created/standardized?