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

Anthony Bryan <anthonybryan@gmail.com> Fri, 09 July 2010 23:44 UTC

Return-Path: <anthonybryan@gmail.com>
X-Original-To: ftpext@core3.amsl.com
Delivered-To: ftpext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B54B3A685A for <ftpext@core3.amsl.com>; Fri, 9 Jul 2010 16:44:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKcinJ6IGHo6 for <ftpext@core3.amsl.com>; Fri, 9 Jul 2010 16:44:52 -0700 (PDT)
Received: from mail-iw0-f181.google.com (mail-iw0-f181.google.com [209.85.214.181]) by core3.amsl.com (Postfix) with ESMTP id 5C92C3A67F0 for <ftpext@core3.amsl.com>; Fri, 9 Jul 2010 16:44:52 -0700 (PDT)
Received: by iwn42 with SMTP id 42so2873212iwn.40 for <ftpext@core3.amsl.com>; Fri, 09 Jul 2010 16:44:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=x9UNPw65fRL2q/6ysm2iNpfCMLWth4WCtQX1hqdUaAw=; b=BRADcXuqBrhVhwtxSxJJ61JzJiBk74lnp4OiUCiwRcby++pCt6Noit8KYAx1N25BZf q4hKrsDkdJ5DNt4TCo0k0lGmr+NsY/e3BSqRuGVEbNUXCpWOkFqL5bTKcwdv1sKstice JL2O0sZOQ5Kfz7DNv6mXniDoBXjjeh9bcRZ0A=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Bwz7/ATlG5s7XYy4wqCPtivgamTn33KldQn0cR3QmFJt/CUySOpyiinyV3KNVejcvd 2283SBFB11ZYGjFKcZSI1KTfZ5m7A8f7xb8WJMQpP09AWJjR7QEtyksB5bKmK3udSuvO dh4JNMtHqcPWBGEOende3equ6NjztXksi3TJY=
MIME-Version: 1.0
Received: by 10.231.174.201 with SMTP id u9mr10620705ibz.17.1278719097277; Fri, 09 Jul 2010 16:44:57 -0700 (PDT)
Received: by 10.231.161.143 with HTTP; Fri, 9 Jul 2010 16:44:57 -0700 (PDT)
In-Reply-To: <4C2F1B7A.2040707@filezilla-project.org>
References: <OF5B8F7FAC.BDF21341-ON80257752.00272796-80257752.002FC71F@uk.ibm.com> <4C2F1B7A.2040707@filezilla-project.org>
Date: Fri, 09 Jul 2010 19:44:57 -0400
Message-ID: <AANLkTinkcSl8PaGIQpJtGPfgGds5MvjXyxZYo1bJVDrJ@mail.gmail.com>
From: Anthony Bryan <anthonybryan@gmail.com>
To: Tim Kosse <tim.kosse@filezilla-project.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: ftpext@core3.amsl.com
Subject: Re: [ftpext] A few comments on draft-bryan-ftp-hash-05
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ftpext>
List-Post: <mailto:ftpext@ietf.org>
List-Help: <mailto:ftpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jul 2010 23:44:53 -0000

On Sat, Jul 3, 2010 at 7:14 AM, Tim Kosse
<tim.kosse@filezilla-project.org> wrote:
> Hi,
>
> thank you very much for your extensive feedback Paul.

yes, thanks, Paul!

> On 2010-06-30 10:50, Paul Ford-Hutchinson wrote:
>> [...]
>> C> HASH filename.ext
>> S> 213 SHA-1 80bc95fd391772fa61c91ed68567f0980bb45fd9 filename.ext
>
> I like this suggestion.
>
>> [...]
>
>> 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."
>
> Makes sense.
>
>> 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"
>
> 551 perhaps?
>
>> Section 6:
>>
>> [...]
>> Not sure that a protocol specification is the right place to place a
>> SHOULD on an implementation decision like this.
>> [...]
>> 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.
>
> Agreed.
>
>
>> Also, if you do start
>> dipping toes into the murky waters of caching, you really need to specify
>> how to update the cached value [...]
>
> What about "A server MAY cache the calculated hashes [...] provided it
> updates or invalidates the cached hash when content of the corresponding
> file changes."
>
>> [...]
>> 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."
>
> Sounds good.
>
>
>>> 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 ...
>> [...]
>
> Yes, that paragraph needs to be improved.
>
>> - 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)
>
> Ack.

the above things are in the -06 draft.

Remaining known issues concerning this draft:

    * Should HASH support partial file hashes, similar to the
Content-MD5 HTTP Header.
    * Section needs improvement: which files should a server process a
HASH command for a logged in user?
    * What should happen if somebody attempts to HASH something that
isn't a file (e.g. it's a directory)?

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