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

Anthony Bryan <anthonybryan@gmail.com> Wed, 19 January 2011 09:42 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 E4CEA3A6FB5 for <ftpext@core3.amsl.com>; Wed, 19 Jan 2011 01:42:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.414
X-Spam-Level:
X-Spam-Status: No, score=-3.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 AtR+Zia-x6Gl for <ftpext@core3.amsl.com>; Wed, 19 Jan 2011 01:42:20 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 988633A7031 for <ftpext@ietf.org>; Wed, 19 Jan 2011 01:42:19 -0800 (PST)
Received: by eyd10 with SMTP id 10so302789eyd.31 for <ftpext@ietf.org>; Wed, 19 Jan 2011 01:44:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QHYfGRS0Jwbq8K+xplPewnQdUMPYfJXHq8712LolylM=; b=WE0e6DwDyRNfyDtpm/lQA6MQmNRQAjs2SrV5d2sYr0lyFE5WgvqvqTcBMK04wM6Tsp u+qzea+m/KkLPbPT/3jH+yi1CVXaZxjbD5T9M0b5994V1fO3l3ZkgM0bhZyKU2r6Q3UX RffNxbNMx6EaHWik+/CBaRAm1j61TlTDnRhHM=
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=RF+vP9TRiOPjHjMYKJOX1xCJYmTsi/u3e/6oQxfb4rCWpbhjuhOWqegytE1KnrjQcF 74fU5b9EQVz8oh0SMn6IJHLyQSGyugsdk57yjVDqC0Cfz7EX/f7u09EYebOOaYwN0n7n JXhwkI22nIBTJw5qTRwID/8zmhTikqXfmOvbA=
MIME-Version: 1.0
Received: by 10.213.28.14 with SMTP id k14mr698780ebc.24.1295430298024; Wed, 19 Jan 2011 01:44:58 -0800 (PST)
Received: by 10.213.9.208 with HTTP; Wed, 19 Jan 2011 01:44:57 -0800 (PST)
In-Reply-To: <F15941D3C8A2D54D92B341C20CACDF2311979DC643@exchange>
References: <F15941D3C8A2D54D92B341C20CACDF2311976FECC9@exchange> <20110117175600.2F89028C1A2@core3.amsl.com> <F15941D3C8A2D54D92B341C20CACDF2311976FF0A8@exchange> <alpine.DEB.2.00.1101181545230.988@tvnag.unkk.fr> <F15941D3C8A2D54D92B341C20CACDF2311979DC5FE@exchange> <alpine.DEB.2.00.1101181656420.988@tvnag.unkk.fr> <F15941D3C8A2D54D92B341C20CACDF2311979DC643@exchange>
Date: Wed, 19 Jan 2011 04:44:57 -0500
Message-ID: <AANLkTi=HwXvyPZ6UebBDA=WBOcLPzjP2qNWCReRLPUbg@mail.gmail.com>
From: Anthony Bryan <anthonybryan@gmail.com>
To: Robert Oslin <rto@globalscape.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "ftpext@ietf.org" <ftpext@ietf.org>
Subject: Re: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm
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: Wed, 19 Jan 2011 09:42:22 -0000

On Tue, Jan 18, 2011 at 11:16 AM, Robert Oslin <rto@globalscape.com> wrote:
> I like the idea of an intermittent 213 reply that would effectively ask the client to hang in there (maybe reset its timeout counter, perhaps with a client defined hard limit to the number of resets in order to prevent malicious use).
>
> This seems in accord with RFC959 section 5.4: Certain commands require a second reply for which the user should also wait.  These replies may, for example, report on the progress or completion of file transfer or the closing of the data connection.  They are secondary replies to file transfer commands.
>
> Anthony, could a provision be made such that a server MAY return a 213 reply every N seconds (5, 15, other) for long running hash operations? I think that would be especially useful if SHA-256 ends up being the default recommended and implemented hash algorithm.

I think we can do anything that is internally consistent within the
FTP universe and seems logical for the published FTP RFCs. :)

> Alternatively client logic could be made to auto-extend the internal timeout when making a hash request for a large file. The draft could recommend either/or approach.
>
> Robert Oslin
>
>
>
>
> -----Original Message-----
> From: Daniel Stenberg [mailto:daniel@haxx.se]
> Sent: Tuesday, January 18, 2011 10:01 AM
> To: Robert Oslin
> Cc: ftpext@ietf.org
> Subject: Re: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm
>
> On Tue, 18 Jan 2011, Robert Oslin wrote:
>
>>>> I personally think CRC32 is too weak for multi-gigabyte files.
>>
>> Do you mean that CRC32 is weak period?
>
> CRC32 uses 32 bits to indicate a checksum for the data. I claim it gets weaker
> the more data to try to check with it. Having a CRC32 field for a sufficiently
> small amount of data will be fine IMO - but that's not what we design for
> here.
>
>> One may argue that the "weaker" the hash the faster it will compute, making
>> it ideal for use with larger files (in order to mitigate the chance of
>> client timeouts).
>
> Clients don't have to timeout. The server can easily send "213-" lines every
> 5-10 seconds or so while calculating the hash. Or is there a reason why not?




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