[ftpext] A few comments on draft-bryan-ftp-hash-05

[Paul Ford-Hutchinson <[e-mail]>]

Hi all, a few comments for you ...

Section 1.1 

I see that somebody has suggested that the 213 HASH reply includes the 
mechanism, may I also suggest that it includes the filespec of the hashed 
file (the thing passed as a parameter in the HASH command).  When writing 
FTP script post-processing logic (as opposed to writing an FTP client) 
having the information on a single line is so so much easier than having 
to remember state as you parse the ftpout file.

e.g. 
C> HASH filename.ext
S> 213 SHA-1 80bc95fd391772fa61c91ed68567f0980bb45fd9 filename.ext

Section 3

>The HASH command is meant to be used for files transmitted in Image
>type mode (TYPE I) and Stream transfer mode (MODE S).  The returned
>hash MUST be calculated over the raw octet data of the file
>irrespective of the selected data type, transfer mode or any other
>state affecting the transfer.  In other words, if a client were to
>download a full file using TYPE I and MODE S and were to calculate
>the hash on the received octet data, it would be identical to the
>hash returned by HASH.

Where the draft states "the raw octet data of the file", it probably needs 
to be making fewer assumptions about the filesystem of the server.  A 
"file" is not necessarily a byte stream.  It may have a record structure 
for example.  I'd remove that sentence and leave it as "The returned hash 
MUST be calculated as if a client were to download the full file using 
TYPE I and MODE S and were to calculate the hash on the received octet 
data."

In which case, one of the replies to the HASH command has to be "5xy I 
cannot calculate the HASH as I would not be able to deliver that file to 
you with TYPE I and MODE S"

Section 3.1

Should there be an allowance for "private" hash algorithms? not just those 
defined in the IANA registry named "Hash Function Textual Names" 

Section 3.4

I think there needs to be the possibility of a temporary refusal to hash a 
file and a permanent refusal to hash a file (i.e. a 4xy if you just don't 
want to hash that file now and a 5xy if you will never hash that file).

4xy could be for performance; user access permissions; file is not 
accessible (opened by another process, being appended to ...); that HASH 
mechanism isn't supported on that file etc...
5xy could be for user profile (i.e. the FTP server doesn't allow this user 
to use the HASH command at all), trying to hash a known special file (e.g. 
/dev/null) etc...

(with different reasons having different values of xy, as defined in 
RFC959 section 4.2)

Section 6:

>Implementing the HASH command may impose a considerable load on the
>server, which could lead to denial-of-service attacks.  Servers have,
>however, implemented this for many years, without significant
>reported difficulties.  On an affected server a malicious user could,
>for example, continuously send HASH commands over multiple
>connections and thus consume most of the FTP server's resources,
>leaving little room for other operations.  To mitigate this risk, a
>server SHOULD cache the calculated hashes so that the hash of a file
>is only calculated once even if multiple hash requests are sent for
>that file.

Not sure that a protocol specification is the right place to place a 
SHOULD on an implementation decision like this.  Also, if you do start 
dipping toes into the murky waters of caching, you really need to specify 
how to update the cached value (for example STOR /xxx.txt; HASH /xxx.txt; 
STOR /xxx.txt; HASH /xxx.txt should return the hash for the second version 
of /xxx.txt and not the cached value from the first.  And there is nothing 
to say that the FTP server is the only thing that might amend the contents 
of /xxx.txt)

>For performance reasons, a server SHOULD a avoid hashing multiple
>files at the same time which are located on the same physical media
>and SHOULD instead hash them sequentially. 

These two SHOULD words should be MAY.  The protocol impact of this is that 
a client MUST allow that a HASH command might take a reasonably long time 
to complete.

>The FTP server's right to
>refuse to calculate the hash is of course important to help against
>denial-of-service risks.  A possible solution is to use the 450 reply
>code of HASH to indicate that the server is already busy with another
>HASH operation.

As a protocol spec, I would re-write something like ...

"A server may refuse to process a HASH command for many reasons, one of 
which may be a suspected denial of service attack, a client MUST be able 
to understand that refusal to process HASH commands may be transient (if 
indicated by a 4xy response) and MAY be honoured later if the server so 
decides."

>In addition, the HASH command can be used to draw conclusions about
>the contents of a file.  If the hash of a file on some server matches
>the hash of some known file, then both files are likely identical.
>To prevent this scenario it suffices to limit use of the HASH command
>to users who would already be able to download the file.

I think the issue of which files a server should process a HASH command 
for a logged in user for is a bit bigger than this ...

- I think this draft needs to be stronger about saying that a HASH command 
MUST only be processable for files to which the server thinks the logged 
in user has a right to access

- There is an issue about 'drop-box' type FTP servers, where I can login, 
dump a file into a write-only directory and might reasonably expect to be 
able to confirm the file isn't broken by subsequently running a HASH 
command against it.  In *IX world with chroot()ed environments, this won't 
work.  The draft should not be silent about this issue.

More discussion required I think


>Currently, some of the hash algorithms defined in the IANA registry
>named "Hash Function Textual Names" are considered insecure.  These
>include the whole Message Digest family of algorithms that are not
>suitable for cryptographically strong verification.  Malicious people
>could provide files that appear to be identical to another file
>because of a collision, i.e., the weak cryptographic hashes of the
>intended file and a substituted malicious file could match.

I'd probably re-write this along the lines that "This mechanism simply 
allows the FTP protocol to expose HASH values of files, using the 
currently chosen mechanism,  accessible to the server by the client.  The 
suitability or otherwise of a specific hash algorithm for a specific 
purpose is an implementation decision."

I would also add some other comments ...

In Security Considerations:

- By uploading a file, running HASH against it and running HASH against 
another file location, the client could infer some filesystem deployment 
information (e.g. that there is a logical link between a pair of 
directories in the tree).  Whilst this is probably not an issue if the 
user has access to both branches of the directory tree, the possibility 
that this information is exposable in this manner should be noted in 
Security Considerations.

General comments

- The draft probably needs to state what should happen if somebody 
attempts to HASH something that isn't a file (e.g. it's a directory)


Cheers,
Paul

-- 

Paul Ford-Hutchinson CISSP - Tivoli Security Consultant
IBM UK Ltd. - NHBR - 1PH - North Harbour - Portsmouth - PO6 3AU

Tel [phone]  (internal: 37269105)