Re: [ftpext] New Version Notification for draft-bryan-ftp-hash-05

[Anthony Bryan <[e-mail]>]

On Mon, Jul 12, 2010 at 7:01 PM, Iljitsch van Beijnum
<[e-mail]> wrote:
> On 13 jul 2010, at 0:39, Anthony Bryan wrote:
>
>> unless I'm misunderstanding, this would be MORE indirect, unoptimized,
>> complex and DoSy than the current draft.
>
> I'll grant you more indirect and more complex. But don't forget the first rule of client-server: let the client do the hard work.

from what I understand, your proposal involves potentially more work
on the server?

>> to be able to answer whether a hash is correct, the server still needs
>> to know the correct hash?
>> when you meet someone, do you ask "is your name Bob? no, how about
>> Jim? no, Ed?" or do you just come right out and ask "what's your
>> name?" which is simpler?
>
> Ah, but the question isn't "what's your name" but something that requires a rather expensive operation, which is always a nice DoS vector.

I don't get it...either way, the server and client both have to
perform the expensive operation, right?

the server caches hashes or can limit the use of HASH, as Paul mentioned...

I haven't heard of this as a problem for Instance Digests (8 years
old), Content-MD5 (15 years), or the current 10 nonstandard FTP
hash/checksum commands (9 years), even though I've brought it up
before.

>> you mention partial file hashes, some of those nonstandard commands
>> like XCRC and XMD5 support it with a byte range.
>> do you think HASH should support partial file hashing?
>
> No, because that way the client could ask the server to do an almost infinite number of hashes on a single file, and it makes it impossible for the server to precompute the hashes.

right, there are reasons against partial file hashes/Content-MD5. does
everyone think they are insurmountable?
I'm personally against it as it involves more work! :)

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads