From iljitsch@muada.com Fri Jul 2 04:16:06 2010 Return-Path: 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 C51B63A68C0 for ; Fri, 2 Jul 2010 04:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=-0.816, BAYES_00=-2.599, SARE_PROLOSTOCK_SYM3=1.63] 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 RvepMYsXHXB5 for ; Fri, 2 Jul 2010 04:15:36 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 300ED3A688A for ; Fri, 2 Jul 2010 04:15:33 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.233]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id o62BFNnM053971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Jul 2010 13:15:23 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Fri, 2 Jul 2010 13:15:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01e201cb0a49$86552b10$7844150a@cisco.com> To: Anthony Bryan X-Mailer: Apple Mail (2.1081) Cc: ftpext@ietf.org Subject: Re: [ftpext] BEHAVE WGLC of draft-ietf-behave-ftp64-03 X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 11:16:06 -0000 On 13 jun 2010, at 7:02, Anthony Bryan wrote: > The first time you use ALG, you want to be clear what it stands for. Ok. > The following sentence sounds weird. Should "so in EPRT translation is > supported" be "so if EPRT translation is supported"? You're right. > NEW > If the client issues the AUTH command, then the client is attempting > to negotiate [RFC2228] security mechanisms which are likely to be > incompatible with the FTP ALG function. Ok. > OLD > "Note that if multiple clients are using the IPv6-to-IPv4 to..." > The IPv6-to-IPv4 what? Changed to "the same IPv6-to-IPv4 translator". > NEW? > The main rationale for ignoring the IPv4 address in the 227 response, > even if the client has IPv4 connectivity, is that most servers will > only allow a data connection from the same client address as seen in > the control channel connection. (See [Bernstein]). I changed this to: The main rationale for ignoring the IPv4 address in the 227 response is = that, even if the client has IPv4 connectivity, most servers will only = allow a data connection from the same client address as seen in the = control channel connection. See . Iljitsch= From iljitsch@muada.com Fri Jul 2 14:53:11 2010 Return-Path: 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 D5CC73A68DA for ; Fri, 2 Jul 2010 14:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.672, 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 Bh39iC2zs9+A for ; Fri, 2 Jul 2010 14:53:11 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id BE8063A68AE for ; Fri, 2 Jul 2010 14:53:10 -0700 (PDT) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id o62Lr3x8058171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 2 Jul 2010 23:53:03 +0200 (CEST) (envelope-from iljitsch@muada.com) From: Iljitsch van Beijnum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Jul 2010 23:53:16 +0200 Message-Id: <4EA20677-B6A7-4CCF-83AE-F4EFC3F92DEE@muada.com> To: ftpext@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [ftpext] updated ftp64 draft X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 21:53:11 -0000 Hi, I updated the BEHAVE FTP64 draft: http://www.ietf.org/internet-drafts/draft-ietf-behave-ftp64-04.txt It went through wglc. We've had a request to delay IETF last call until = after the FTPEXT2 BoF. I would be much obliged if a few more people = could review it, and those who already did so can check if the latest = version addresses their comments and doesn't introduce any new issues, a = diff should soon be available here: http://tools.ietf.org/html/draft-ietf-behave-ftp64-04 If anyone wants to talk in person in Maastricht, let me know and I can = see if we can arrange that.= From tim.kosse@filezilla-project.org Sat Jul 3 03:16:00 2010 Return-Path: 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 E727E3A689C for ; Sat, 3 Jul 2010 03:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 SGm1fjkR1Dpn for ; Sat, 3 Jul 2010 03:15:58 -0700 (PDT) Received: from filezilla-project.org (cl-1464.dus-01.de.sixxs.net [IPv6:2a01:198:200:5b7::2]) by core3.amsl.com (Postfix) with ESMTP id 4154D3A6828 for ; Sat, 3 Jul 2010 03:15:58 -0700 (PDT) Received: from [2a01:198:458::59] by filezilla-project.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1OUzlX-0007oP-Fp; Sat, 03 Jul 2010 12:16:07 +0200 Message-ID: <4C2F0DDF.5010900@filezilla-project.org> Date: Sat, 03 Jul 2010 12:15:59 +0200 From: Tim Kosse User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Anthony Bryan References: <20100629052221.092623A6A5C@core3.amsl.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBEAF5F7C896052C8718A77B7" Cc: ftpext@ietf.org Subject: Re: [ftpext] New Version Notification for draft-bryan-ftp-hash-05 X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 10:16:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBEAF5F7C896052C8718A77B7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2010-06-30 01:34, Anthony Bryan wrote: > after reading draft-somers-ftp-mfxx-04, maybe we should import > pathname from section 2.2 of RFC 3659? Yes, that makes sense. Tim --------------enigBEAF5F7C896052C8718A77B7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwvDeMACgkQ8N9+lcqiUkW2CgCg9DHyXhwibMMzNGWNiKTMW93X 5DEAnA90je1Bjmot7sIcCvsBEfyc1Oy3 =qHzq -----END PGP SIGNATURE----- --------------enigBEAF5F7C896052C8718A77B7-- From tim.kosse@filezilla-project.org Sat Jul 3 04:14:41 2010 Return-Path: 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 3F4F03A6992 for ; Sat, 3 Jul 2010 04:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=-1.208, BAYES_40=-0.185] 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 O7OYsMjBaEDS for ; Sat, 3 Jul 2010 04:13:55 -0700 (PDT) Received: from filezilla-project.org (filezilla-project.org [213.239.222.5]) by core3.amsl.com (Postfix) with ESMTP id AD18D3A68BC for ; Sat, 3 Jul 2010 04:13:55 -0700 (PDT) Received: from [2a01:198:458::59] by filezilla-project.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1OV0fd-0007yS-Na; Sat, 03 Jul 2010 13:14:06 +0200 Message-ID: <4C2F1B7A.2040707@filezilla-project.org> Date: Sat, 03 Jul 2010 13:14:02 +0200 From: Tim Kosse User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Paul Ford-Hutchinson References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD125AF2F457405A3C695EE42" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 11:14:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD125AF2F457405A3C695EE42 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, thank you very much for your extensive feedback 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 ne= eds=20 > to be making fewer assumptions about the filesystem of the server. A=20 > "file" is not necessarily a byte stream. It may have a record structur= e=20 > for example. I'd remove that sentence and leave it as "The returned ha= sh=20 > 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 t= o=20 > you with TYPE I and MODE S" 551 perhaps? > Should there be an allowance for "private" hash algorithms? not just th= ose=20 > defined in the IANA registry named "Hash Function Textual Names"=20 Should be fine to allow provided algorithms provided that there is a prefix to distinguish between registered and private algorithms, X_ perha= ps. Also, it needs to be made clear that the private algorithms are not interoperable, as two servers might implement two completely different algorithms using the same private name. > Section 6: >=20 > [...] > Not sure that a protocol specification is the right place to place a=20 > SHOULD on an implementation decision like this.=20 > [...] > These two SHOULD words should be MAY. The protocol impact of this is t= hat=20 > a client MUST allow that a HASH command might take a reasonably long ti= me=20 > to complete. Agreed. > Also, if you do start=20 > dipping toes into the murky waters of caching, you really need to speci= fy=20 > 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 ... >=20 > "A server may refuse to process a HASH command for many reasons, one of= =20 > which may be a suspected denial of service attack, a client MUST be abl= e=20 > to understand that refusal to process HASH commands may be transient (i= f=20 > indicated by a 4xy response) and MAY be honoured later if the server so= =20 > 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. >=20 > I think the issue of which files a server should process a HASH command= =20 > 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=20 > attempts to HASH something that isn't a file (e.g. it's a directory) Ack. Regards, Tim --------------enigD125AF2F457405A3C695EE42 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwvG3oACgkQ8N9+lcqiUkUipQCcC4IX2Q5jGvMlELwpG5Lr+OZn D+cAoMPmfebZQlIIZjTek+2mUYsPk3Ad =yF3W -----END PGP SIGNATURE----- --------------enigD125AF2F457405A3C695EE42-- From anthonybryan@gmail.com Sat Jul 3 14:50:49 2010 Return-Path: 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 22AF43A677C for ; Sat, 3 Jul 2010 14:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 yZv8ot+EWfmR for ; Sat, 3 Jul 2010 14:50:42 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C4A623A684E for ; Sat, 3 Jul 2010 14:50:39 -0700 (PDT) Received: by iwn10 with SMTP id 10so2127546iwn.31 for ; Sat, 03 Jul 2010 14:50:39 -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=9MhUAyGgruBRP2Ul+7pSCRvUMSNxl4483Qv2Jb4QK54=; b=pNMu3Afzy8+iqB+G3krmMqdoUGgP0nYtFm9q3up03HAr0gWkzYc8FWKUvmpPAI5fIU 1JoBO5eFIHiKA08VIrVCmrec6ngV2rS34mVHfocrGX0ngkXr7RyRQyAwK0njZfYauzox yBnuwYhpmNkCMXZBZfqw5ZF54VBhZkg3qNLCA= 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=w1fZdeocpYXWTxbvanGZwnw4DP5k9VzOU1llyXRPFNEulsq34dqK45SpWpI0dydRrL /09At3XTdO23w9JNOcnZGxEfCbKtOPd+zWwDStBBQ1e0NlmkqAHgTaZRqc6RPc3KlRXn WVDUEOW+JFSOsRiwusf3vzdv38vhXt+lcHyNE= MIME-Version: 1.0 Received: by 10.231.32.71 with SMTP id b7mr867471ibd.198.1278193838838; Sat, 03 Jul 2010 14:50:38 -0700 (PDT) Received: by 10.231.195.91 with HTTP; Sat, 3 Jul 2010 14:50:38 -0700 (PDT) In-Reply-To: References: Date: Sat, 3 Jul 2010 17:50:38 -0400 Message-ID: From: Anthony Bryan To: barryleiba@computer.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] Working on the ftpext2 BOF agenda... X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 21:50:49 -0000 On Thu, Jun 24, 2010 at 10:29 PM, Barry Leiba wrote: > As I prepare an agenda for the (two-hour) ftpext2 BOF, I want to know > which drafts people think we should be discussing/considering. =A0Please > look at Anthony's message: > =A0 http://www.ietf.org/mail-archive/web/ftpext/current/msg00014.html > > ...and post *here*, in this thread, which drafts you have interest in. > =A0You may select from the active drafts and the expired ones. =A0Please > also let me know if you will (1) be in Maastricht and attending the > BOF, (2) be in Maastricht but not attending the BOF, or (3) be > attending the BOF remotely, through Jabber and/or the audio feed. > > Please just use this thread for direct response to this message, > including any other agenda requests. =A0Put any discussion in Anthony's > thread or start another. =A0Thanks. I'd like to have draft-bryan-ftp-hash on the agenda. we plan to have an updated version in time for the BOF. when is the cutoff date, a few days before the meeting? Daniel Stenberg plans to physically be at the BOF I believe. I will be attending remotely. can you offer instructions on doing that closer to the date? thanks, --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From barryleiba.mailing.lists@gmail.com Fri Jul 9 10:45:40 2010 Return-Path: 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 283DC3A6AD4 for ; Fri, 9 Jul 2010 10:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 LZM1G1ABeVWK for ; Fri, 9 Jul 2010 10:45:39 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 388E23A6AA8 for ; Fri, 9 Jul 2010 10:45:39 -0700 (PDT) Received: by gxk3 with SMTP id 3so1549140gxk.31 for ; Fri, 09 Jul 2010 10:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:content-type; bh=Fbp0aY4oRDVXSuBw3UxBvCucNJiKwpBYxQKgrBuLE1Q=; b=v7d/PcShjkJ4gEwWjZ0GbWwB0EPQSJ2MfzCI11pvkPP+e1db+gqe1GEhLiL1E+MjoB utoKaWQDGYl7Mw55YqoTrZ61vXb6TBDt6TKGM0MhlAk4uvR7yPumAuKTDtXh5cEebTYL rkPMwWN1xb8DIxD1JMJWj59BXlSdd64N1yeQk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=joYLTJpz066sAXZuDgY/koNyrnv+3zMcnbYkrz3zo3CG+Bh+MIE+MkGZiAaeNiLfAS DWUeEeYwUaK8VxnB+mc7Os/AK2kZrYAb6Ei0WwVZXY48Y5wIRfY97Ex72TTVuFp+1qEO K4d0MESZ+VwDEZyMbbeTP0NN5cMKj09GdPaZA= MIME-Version: 1.0 Received: by 10.150.97.21 with SMTP id u21mr2274229ybb.77.1278697540618; Fri, 09 Jul 2010 10:45:40 -0700 (PDT) Received: by 10.42.5.212 with HTTP; Fri, 9 Jul 2010 10:45:40 -0700 (PDT) In-Reply-To: References: Date: Fri, 9 Jul 2010 13:45:40 -0400 Message-ID: From: Barry Leiba To: ftpext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [ftpext] Working on the ftpext2 BOF agenda... X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 17:45:40 -0000 OK, setting up an agenda for the WG meeting in Maastricht... We're scheduled to meet for 2 hours, on Monday afternoon (26 July) from 17:40 to 19:40 CET (15:40 to 17:40 UTC). I'm including a skeleton agenda, below. I'd like to hear about other agenda items people have to propose, or any other comments about the skeleton agenda. I'd also like more of a "show of hands" to let me know who's going to be attending in person, and who will participate remotely, using the audio stream or jabber. We've had only one response to that. Please reply to this thread with answers to these questions, and other issues directly related to the Maastricht meeting. Note that there's time on the agenda to discuss a few specific drafts. That done, it's not the primary purpose of this session to go into detail on the drafts, but to look at how we should be coordinating FTP extension work, and whether we have the critical mass of work and interest to form a working group. I expect that the draft discussions will be fairly high level, and relatively brief. Here's a skeleton agenda, with no times on it yet: 1. Welcome and announcements. 2. Background and purpose of the BoF. 3. General discussion of interest in FTP extensions. 4. Document discussions... a. draft-ietf-behave-ftp64[1] b. draft-liu-behave-ftp64[2] c. draft-bryan-ftp-hash[3] d. draft-hethmon-mcmurray-ftp-hosts[4] e. draft-peterson-streamlined-ftp-command-extensions[5] f. other documents... 5. Questions about working-group formation. 6. Next steps. Barry, as chair [1] http://tools.ietf.org/html/draft-ietf-behave-ftp64 [2] http://tools.ietf.org/html/draft-liu-behave-ftp64 [3] http://tools.ietf.org/html/draft-bryan-ftp-hash [4] http://tools.ietf.org/html/draft-hethmon-mcmurray-ftp-hosts [5] http://tools.ietf.org/html/draft-peterson-streamlined-ftp-command-extensions From anthonybryan@gmail.com Fri Jul 9 11:43:49 2010 Return-Path: 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 A5CD43A6861 for ; Fri, 9 Jul 2010 11:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 O6SHIzPt5SWe for ; Fri, 9 Jul 2010 11:43:48 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8251A3A6838 for ; Fri, 9 Jul 2010 11:43:48 -0700 (PDT) Received: by iwn38 with SMTP id 38so2587237iwn.31 for ; Fri, 09 Jul 2010 11:43:53 -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:content-type :content-transfer-encoding; bh=2IGzeYnFY7oQuThFG8U+aSiJ5X6BPm95xQoyyS9mIOE=; b=Izygwu9Fp+A5RefvWkRhz+cZvpwBAqiZ/EUuamABEUKlcLVn1P13w3TRgyrWCN2Id5 pHGnuGEZCRAjI6q4tzLqh6Zzw/TWRg1j+03auKbFpk1r+0elVTfiBV9OnK+q7ZCohhVO H3fyDUBP5qG5UV2IAEEMmsa0udG/rbT7P3CzM= 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 :content-type:content-transfer-encoding; b=ZqjyqkwJYDsJJ3GmpxQP3XpSb9o0ZcXEJKfVSOrOATcIkVYw2WrSlpAZJAF4BVV+Mz RVFrKjJr1ufhNGnKlTusViBYbUvnffO5qOjr2hT4WCynsiKFlAIFMMimnZm0DpG9F3OR mAu7CiXvrKlKUIcZJ7YPKx9aPUicK0mKU2Q/w= MIME-Version: 1.0 Received: by 10.42.0.3 with SMTP id 3mr3366242ica.47.1278701033288; Fri, 09 Jul 2010 11:43:53 -0700 (PDT) Received: by 10.231.161.143 with HTTP; Fri, 9 Jul 2010 11:43:53 -0700 (PDT) In-Reply-To: References: Date: Fri, 9 Jul 2010 14:43:53 -0400 Message-ID: From: Anthony Bryan To: ftpext@ietf.org, mpp@rhinosoft.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [ftpext] Expired FTP ID review: draft-peterson-streamlined-ftp-command-extensions-06 X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 18:43:49 -0000 On Sat, Jun 26, 2010 at 4:00 PM, Anthony Bryan wro= te: > this ID describes 6 new commands, of which HOST is more fully > described in draft-hethmon-mcmurray-ftp-hosts. > > the other 5 commands: > > Remove Directory All (RMDA) > Directory Size (DSIZ) > Available Octets (AVBL) [similar to LOCAL DISK SIZE (LDSIZE) from > draft-dilip-ftpext-safe-transfer-00] > Retrieve Thumbnail of Remote Image File (THMB) > Client / Server Identification (CSID) I see an updated version is available that removed HOST http://tools.ietf.org/html/draft-peterson-streamlined-ftp-command-extension= s I think you also want to add an informative reference to RFC 5797 and add the commands in the IANA sections similar to the other drafts. http://tools.ietf.org/html/draft-bryan-ftp-hash-05#section-4 http://tools.ietf.org/html/draft-hethmon-mcmurray-ftp-hosts-15#section-5 --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From barryleiba.mailing.lists@gmail.com Fri Jul 9 13:09:03 2010 Return-Path: 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 5E6F03A68BD for ; Fri, 9 Jul 2010 13:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 PJkSjOtzUEaO for ; Fri, 9 Jul 2010 13:09:02 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 861143A68B0 for ; Fri, 9 Jul 2010 13:09:02 -0700 (PDT) Received: by gyh3 with SMTP id 3so1644208gyh.31 for ; Fri, 09 Jul 2010 13:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=qjaWCQEk5BZT+OM53GJTTLFTDP2g/Vn4G523EH3hAJQ=; b=KpTnrggkdBk6+seNeDZWf8YUCC0PPlelX+t0n/MkdQ1X5/Oyljv/yU2h3hWER+Ysfa rArFHhGY7sEqbTtXc7XD908W5/ldty1i5tWZD+Gc6RFhyI+7l1TO/4hcpYAVP7lw053a GUHqOGLbPfiN8PCS7Kd1WJbEiVyFX+1h8vyJQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=pMybT8bv2CUcli/PMYyAWW5vvzQ+TpMYaRFor/a+0L/Nag65E1bjr8+ap53w1ngLPV 3WOzhnsiPwP2S1wi4xV7jPdPqEHZQ900c/Y9O8U7KwxM/HgGI70GYbeh9TYG3FA7YNDW XGcevux0BcbGYh9QUNi0O1tBPeN/7eVdmXKig= MIME-Version: 1.0 Received: by 10.151.63.22 with SMTP id q22mr2491775ybk.106.1278706144365; Fri, 09 Jul 2010 13:09:04 -0700 (PDT) Received: by 10.42.5.212 with HTTP; Fri, 9 Jul 2010 13:09:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 9 Jul 2010 16:09:04 -0400 Message-ID: From: Barry Leiba To: Anthony Bryan Content-Type: text/plain; charset=ISO-8859-1 Cc: ftpext@ietf.org Subject: Re: [ftpext] Working on the ftpext2 BOF agenda... X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 20:09:03 -0000 I'm sorry: I missed that there was a question here, which I hadn't replied to. On Sat, Jul 3, 2010 at 5:50 PM, Anthony Bryan wrote: > I'd like to have draft-bryan-ftp-hash on the agenda. we plan to have > an updated version in time for the BOF. when is the cutoff date, a few > days before the meeting? The cutoff for draft submissions is this coming Monday, 12 July, at 17:00 Pacific Time (2400 UTC). See http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF78 Barry From barryleiba.mailing.lists@gmail.com Fri Jul 9 13:19:23 2010 Return-Path: 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 C7C7F3A68CC for ; Fri, 9 Jul 2010 13:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=-0.286, 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 LxYqvZdZcYzH for ; Fri, 9 Jul 2010 13:19:12 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id B84C73A68C1 for ; Fri, 9 Jul 2010 13:19:07 -0700 (PDT) Received: by gyh3 with SMTP id 3so1651809gyh.31 for ; Fri, 09 Jul 2010 13:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=9Ev+uPYJtOK6iDO+oW0sshXv8R9V47uMOIa8uBJEd9A=; b=V/jOTYrqg3LUDJrGzl2lR0PhiAz7mvmEvClLmDEZDrmzvJ0o/TDhFPjgUp19DBdP2B vtSBNhVyAJZXjPQDMPDwHEb2EDC53qnc12SlSMJtldpKppJjrgNYv7QDlXCrqBzoCdpr vTAAK2W6vc6o2Zuo86Xe6dI385QRLJgGm5n40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; b=OFKBWt/rJdRv26u/wOaCBlpchKvlbAgLCQ+eeyvY3BZcE3pwtIt+U+YOTdX5yfWll0 nlIA4kp+tKp5ikgK25Oit8Y0z4Qb6GID85djGdDaxSSB55WrWcPYc66knDqrF2LJSENo Tm9xFgqyM0Sr6hRolOU6OwZ/JieIWqaiPVAzI= MIME-Version: 1.0 Received: by 10.151.5.15 with SMTP id h15mr2270813ybi.268.1278706750257; Fri, 09 Jul 2010 13:19:10 -0700 (PDT) Received: by 10.42.5.212 with HTTP; Fri, 9 Jul 2010 13:19:10 -0700 (PDT) In-Reply-To: References: Date: Fri, 9 Jul 2010 16:19:10 -0400 Message-ID: From: Barry Leiba To: ftpext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [ftpext] Working on the ftpext2 BOF agenda... X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 20:19:23 -0000 > Here's a skeleton agenda, with no times on it yet: > 1. Welcome and announcements. > 2. Background and purpose of the BoF. > 3. General discussion of interest in FTP extensions. > 4. Document discussions... > =A0 a. draft-ietf-behave-ftp64[1] > =A0 b. draft-liu-behave-ftp64[2] > =A0 c. draft-bryan-ftp-hash[3] > =A0 d. draft-hethmon-mcmurray-ftp-hosts[4] > =A0 e. draft-peterson-streamlined-ftp-command-extensions[5] > =A0 f. other documents... > 5. Questions about working-group formation. > 6. Next steps. > > > [1] http://tools.ietf.org/html/draft-ietf-behave-ftp64 > [2] http://tools.ietf.org/html/draft-liu-behave-ftp64 > [3] http://tools.ietf.org/html/draft-bryan-ftp-hash > [4] http://tools.ietf.org/html/draft-hethmon-mcmurray-ftp-hosts > [5] http://tools.ietf.org/html/draft-peterson-streamlined-ftp-command-ext= ensions > Update: 4f. draft-preston-ftpext-deflate[6] 4g. other documents... [6] http://tools.ietf.org/html/draft-preston-ftpext-deflate Barry, as chair From anthonybryan@gmail.com Fri Jul 9 16:44:53 2010 Return-Path: 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 ; 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 ; 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 ; Fri, 9 Jul 2010 16:44:52 -0700 (PDT) Received: by iwn42 with SMTP id 42so2873212iwn.40 for ; 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: <4C2F1B7A.2040707@filezilla-project.org> Date: Fri, 9 Jul 2010 19:44:57 -0400 Message-ID: From: Anthony Bryan To: Tim Kosse 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 23:44:53 -0000 On Sat, Jul 3, 2010 at 7:14 AM, Tim Kosse 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 nee= ds >> to be making fewer assumptions about the filesystem of the server. =A0A >> "file" is not necessarily a byte stream. =A0It may have a record structu= re >> for example. =A0I'd remove that sentence and leave it as "The returned h= ash >> 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. =A0The protocol impact of this is = that >> a client MUST allow that a HASH command might take a reasonably long tim= e >> to complete. > > Agreed. > > >> Also, if you do start >> dipping toes into the murky waters of caching, you really need to specif= y >> 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. =A0If 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)? --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From iljitsch@muada.com Mon Jul 12 02:59:29 2010 Return-Path: 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 366BA3A67A5 for ; Mon, 12 Jul 2010 02:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 exAbBJz+q469 for ; Mon, 12 Jul 2010 02:59:28 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 329033A67C3 for ; Mon, 12 Jul 2010 02:59:27 -0700 (PDT) Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id o6C9x8NO063171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 12 Jul 2010 11:59:09 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Iljitsch van Beijnum In-Reply-To: Date: Mon, 12 Jul 2010 11:59:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100629052221.092623A6A5C@core3.amsl.com> To: ftpext@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [ftpext] New Version Notification for draft-bryan-ftp-hash-05 X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 09:59:29 -0000 A more efficient and less DoS-prone way to implement this would be for = the client to tell the server the hash, and for the server to tell the = client whether the file matches the hash. To optimize this, the hash wouldn't be a straigh hash over the entire = file, but consist of three parts: the file length, a hash over a small = part of the file (say, the first and last kilobyte) and finally a hash = over the entire file. So if the length doesn't match, the file doesn't = match the hash and there is no need to access the file. If the hash over = the small part doesn't match, there is no match and hashing the entire = file is avoided. Nitpick: repeating the first part of the abstract in the introduction = verbatim is a bit annoying.= From paulfordh@uk.ibm.com Mon Jul 12 14:54:45 2010 Return-Path: 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 6A16F3A6878 for ; Mon, 12 Jul 2010 14:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 u8ybYtLE2EmK for ; Mon, 12 Jul 2010 14:54:44 -0700 (PDT) Received: from mtagate1.uk.ibm.com (mtagate1.uk.ibm.com [194.196.100.161]) by core3.amsl.com (Postfix) with ESMTP id D247C3A6B63 for ; Mon, 12 Jul 2010 14:54:42 -0700 (PDT) Received: from d06nrmr1707.portsmouth.uk.ibm.com (d06nrmr1707.portsmouth.uk.ibm.com [9.149.39.225]) by mtagate1.uk.ibm.com (8.13.1/8.13.1) with ESMTP id o6CLsn8U005826 for ; Mon, 12 Jul 2010 21:54:49 GMT Received: from d06av06.portsmouth.uk.ibm.com (d06av06.portsmouth.uk.ibm.com [9.149.37.217]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o6CLsn041585194 for ; Mon, 12 Jul 2010 22:54:49 +0100 Received: from d06av06.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o6CLsnpo011821 for ; Mon, 12 Jul 2010 15:54:49 -0600 Received: from d06ml069.portsmouth.uk.ibm.com (d06ml069.portsmouth.uk.ibm.com [9.149.38.218]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o6CLsnhb011817 for ; Mon, 12 Jul 2010 15:54:49 -0600 In-Reply-To: References: <20100629052221.092623A6A5C@core3.amsl.com>

To: ftpext@ietf.org MIME-Version: 1.0 X-KeepSent: 14A91796:C0BA21B6-8025775E:0076E406; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 From: Paul Ford-Hutchinson Message-ID: Date: Mon, 12 Jul 2010 23:03:22 +0100 X-MIMETrack: Serialize by Router on D06ML069/06/M/IBM(Release 8.0.2FP2|June 22, 2009) at 12/07/2010 23:03:22, Serialize complete at 12/07/2010 23:03:22 Content-Type: multipart/alternative; boundary="=_alternative 00785AA28025775E_=" Subject: Re: [ftpext] New Version Notification for draft-bryan-ftp-hash-05 X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 21:54:45 -0000 This is a multipart message in MIME format. --=_alternative 00785AA28025775E_= Content-Type: text/plain; charset="US-ASCII" > Iljitsch van Beijnum wrote on 12/07/2010 10:59:32: > > A more efficient and less DoS-prone way to implement this would be > for the client to tell the server the hash, and for the server to > tell the client whether the file matches the hash. Not sure how this reduces DoS - if a client can STOR/RETR a file then they know the length and 'mini-hash' and thence force the server to repeatedly calculate the full hash. (And if the server is caching the hash, then this isn't a DoS issue in the first place). > > To optimize this, the hash wouldn't be a straigh hash over the > entire file, but consist of three parts: the file length, a hash > over a small part of the file (say, the first and last kilobyte) and > finally a hash over the entire file. So if the length doesn't match, > the file doesn't match the hash and there is no need to access the > file. If the hash over the small part doesn't match, there is no > match and hashing the entire file is avoided. my 2c - this is an unnecessary complication to address a possible threat that can be managed by other mechanisms (throttling HASH requests from a given client, caching the hash, ...) Paul --=_alternative 00785AA28025775E_= Content-Type: text/html; charset="US-ASCII"
> Iljitsch van Beijnum wrote on 12/07/2010 10:59:32:
> > A more efficient and less DoS-prone way to implement this would be > for the client to tell the server the hash, and for the server to > tell the client whether the file matches the hash.

Not sure how this reduces DoS - if a client can STOR/RETR a file then they know the length and 'mini-hash' and thence force the server to repeatedly calculate the full hash. (And if the server is caching the hash, then this isn't a DoS issue in the first place).
> > To optimize this, the hash wouldn't be a straigh hash over the > entire file, but consist of three parts: the file length, a hash > over a small part of the file (say, the first and last kilobyte) and > finally a hash over the entire file. So if the length doesn't match, > the file doesn't match the hash and there is no need to access the > file. If the hash over the small part doesn't match, there is no > match and hashing the entire file is avoided.
my 2c - this is an unnecessary complication to address a possible threat that can be managed by other mechanisms (throttling HASH requests from a given client, caching the hash, ...)
Paul --=_alternative 00785AA28025775E_=-- From anthonybryan@gmail.com Mon Jul 12 15:39:14 2010 Return-Path: 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 780183A687D for ; Mon, 12 Jul 2010 15:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 H0FU2BC4umh6 for ; Mon, 12 Jul 2010 15:39:12 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 9F9E53A681D for ; Mon, 12 Jul 2010 15:39:12 -0700 (PDT) Received: by mail-iw0-f172.google.com with SMTP id 38so5368504iwn.31 for ; Mon, 12 Jul 2010 15:39:21 -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=i8RtZUtQyHEcTWPuswjNnuf8tWH4NsXeAPCWm1cWHug=; b=QxQ85aahqokZ6Iq0+v+oKEykJFPGE8DhOxX8D3ruavbIHs4uLU4TvjWFeG2Qnk4Vza jV9kMM9BPdJNijlCOOrvl2Pv0HN0qeWZSj80SPD7WyxP50Mzp4HzeCTXMo7xGGbRdAF4 865ANhMUWRaMOGRTNWoTo5Hzxx7p8nY9GS6xA= 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=YVk620KvM8FEM3NyYKsXE6yVpgFABDO0KKHriyW3aO81SxYpbyhM3jnlR4C5RnO3IM wVSvkB8SrSChgLcF3Pu9mPeFj24NTvpREyz9EB5W1YHa5LRdp5ByVe2NE1Pd1EGcmOie vxq+mFc0RpOYAon4jFR+T9hmLjjO3s7EEfR/U= MIME-Version: 1.0 Received: by 10.231.37.75 with SMTP id w11mr12806577ibd.45.1278974360686; Mon, 12 Jul 2010 15:39:20 -0700 (PDT) Received: by 10.231.161.143 with HTTP; Mon, 12 Jul 2010 15:39:20 -0700 (PDT) In-Reply-To: References: <20100629052221.092623A6A5C@core3.amsl.com>

Date: Mon, 12 Jul 2010 18:39:20 -0400 Message-ID: From: Anthony Bryan To: Iljitsch van Beijnum Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] New Version Notification for draft-bryan-ftp-hash-05 X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 22:39:14 -0000 On Mon, Jul 12, 2010 at 5:59 AM, Iljitsch van Beijnum wrote: > A more efficient and less DoS-prone way to implement this would be for th= e client to tell the server the hash, and for the server to tell the client= whether the file matches the hash. > > To optimize this, the hash wouldn't be a straigh hash over the entire fil= e, but consist of three parts: the file length, a hash over a small part of= the file (say, the first and last kilobyte) and finally a hash over the en= tire file. So if the length doesn't match, the file doesn't match the hash = and there is no need to access the file. If the hash over the small part do= esn't match, there is no match and hashing the entire file is avoided. Iljitsch, interesting approach. I believe one of the draft's earlier incarnations also had a CHKHSH command which did just this. unless I'm misunderstanding, this would be MORE indirect, unoptimized, complex and DoSy than the current draft. 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? MirrorBrain is an example of a server, although HTTP not FTP, that is a hash/mirror cache/provider: http://www.mirrorbrain.org/ it also might be worth examining what the other FTP servers that implement the nonstandard hash commands do. 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? > Nitpick: repeating the first part of the abstract in the introduction ver= batim is a bit annoying. sure, we'll work on that. --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From iljitsch@muada.com Mon Jul 12 16:01:40 2010 Return-Path: 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 D98423A6860 for ; Mon, 12 Jul 2010 16:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 aKiZ3WdjqYas for ; Mon, 12 Jul 2010 16:01:37 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id DF4FD3A68B1 for ; Mon, 12 Jul 2010 16:01:28 -0700 (PDT) Received: from [IPv6:2001:960:7bf:f:223:12ff:fe56:36b2] ([IPv6:2001:960:7bf:f:223:12ff:fe56:36b2]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id o6CN17Nc088593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Jul 2010 01:01:08 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Tue, 13 Jul 2010 01:01:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100629052221.092623A6A5C@core3.amsl.com>

Date: Mon, 12 Jul 2010 20:12:22 -0400 Message-ID: From: Anthony Bryan To: Iljitsch van Beijnum Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] New Version Notification for draft-bryan-ftp-hash-05 X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 00:12:18 -0000 On Mon, Jul 12, 2010 at 7:01 PM, Iljitsch van Beijnum 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 infi= nite 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! :) --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From iljitsch@muada.com Tue Jul 13 04:10:14 2010 Return-Path: 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 9C9763A68D6 for ; Tue, 13 Jul 2010 04:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 F6o6g5MWc--0 for ; Tue, 13 Jul 2010 04:10:13 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 730673A6978 for ; Tue, 13 Jul 2010 04:10:13 -0700 (PDT) Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id o6DB9qTO098443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Jul 2010 13:09:53 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: Date: Tue, 13 Jul 2010 13:10:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4458F933-86BD-4723-BAC4-CE8E8FBA348F@muada.com> References: <20100629052221.092623A6A5C@core3.amsl.com>

To: Anthony Bryan X-Mailer: Apple Mail (2.1081) Cc: ftpext@ietf.org Subject: Re: [ftpext] New Version Notification for draft-bryan-ftp-hash-05 X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 11:10:14 -0000 On 13 jul 2010, at 2:12, Anthony Bryan wrote: >> 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? If the hashes match then the extra check for the size and the small hash = are unnecessary extra work, yes. But you only have to be able to skip = hashing a multi-GB file once in a while to make up for that. >> 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? A malicious client could ask the server for hashes for all files it has. = In my scheme, the amount of work done by the server is limited to = computing the short hash, unless the malicious client has the full file = or its full hash, in which case the client can get the server to compute = hashes over the entire files. In the non-malicious case you still get to save work some of the time. BTW, try this for fun: type md5 and try to use your = computer as normal: load a big web page, start an application. > 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. As commercials for financial services keep telling us: past performance = doesn't guarantee future performance.= From Richard.Koenning@ts.fujitsu.com Tue Jul 13 06:13:15 2010 Return-Path: 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 584193A688D for ; Tue, 13 Jul 2010 06:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 2enYIXSHF+i9 for ; Tue, 13 Jul 2010 06:13:13 -0700 (PDT) Received: from dgate10.ts.fujitsu.com (dgate10.ts.fujitsu.com [80.70.172.49]) by core3.amsl.com (Postfix) with ESMTP id CAC743A67ED for ; Tue, 13 Jul 2010 06:13:12 -0700 (PDT) DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Message-ID:Date:From:Reply-To:Organization: User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type: Content-Transfer-Encoding; b=DZAeOa1S0lnQ+TseWvKIU6rHy3ISLzXQ4YjJmCrY861uKimFxY8mmvvn Dg9E2CMY3ByfavpBSYiCINaPlNwaa4K+3lMlW0ZCiYVjM61L987ii9pCV Yi3E2QuMDClJ8rJHvvhHRdDkT3lPF2riTSYzHL/rhxPwPikewsJAcRhwc q5vEj/aX1P0yZ09tMUVROBZ5wzAoreHDaQDz9/zftWn6zczc4G09zgTZr X2ZetW5oalBPUGOKYOopvuNK0pKwc; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=Richard.Koenning@ts.fujitsu.com; q=dns/txt; s=s1536b; t=1279026853; x=1310562853; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<4C3C666F.2080509@ts.fujitsu.com>|Date:=20 Tue,=2013=20Jul=202010=2015:13:19=20+0200|From:=20Richard =20Koenning=20|Reply-To: =20=20Richard.Koenning@ts.fujitsu.com|MIME-Version:=201.0 |To:=20"ftpext@ietf.org"=20|CC:=20Iljits ch=20van=20Beijnum=20|Subject:=20Re: =20[ftpext]=20New=20Version=20Notification=20for=20draft- bryan-ftp-hash-05|References:=20<20100629052221.092623A6A 5C@core3.amsl.com>=09=09=09=09=09=09=09=20<4458F933-86BD-4723-BA C4-CE8E8FBA348F@muada.com>|In-Reply-To:=20<4458F933-86BD- 4723-BAC4-CE8E8FBA348F@muada.com> |Content-Transfer-Encoding:=20quoted-printable; bh=I9n128j0Tu9+9I3UE1sWykaMT8lkyacZB86HQAZe4U8=; b=lWRocja+aXqd+rcdcvPmsLvrooE9eQXyEONflSBHtgH6NoN43Q4w3bHK TBjg/K6LHW62AaOB42nzbw2PATft+8eFqRBHTMjC8fWy2B0639Z2rNmQT WfD5ToFOTnRhDfgixji7zEQi84OoXC9q65LLBErShrXsyfNkGaAmGvpHo Y5fO2k71XyowWWdFVhotOnVxNwjOn7vapo4iMDf3ajuj3yzmW78PaWaoC wnz8PilnesYQBzMdIU5BZnmBLKpg0; X-SBRSScore: None X-IronPort-AV: E=Sophos;i="4.55,193,1278280800"; d="scan'208";a="41486588" Received: from abgdgate30u.abg.fsc.net ([172.25.138.66]) by dgate10u.abg.fsc.net with ESMTP; 13 Jul 2010 15:14:10 +0200 X-IronPort-AV: E=Sophos;i="4.55,195,1278280800"; d="scan'208";a="95545696" Received: from mch8469d.mch.fsc.net (HELO [172.25.52.240]) ([172.25.52.240]) by abgdgate30u.abg.fsc.net with ESMTP; 13 Jul 2010 15:13:19 +0200 Message-ID: <4C3C666F.2080509@ts.fujitsu.com> Date: Tue, 13 Jul 2010 15:13:19 +0200 From: Richard Koenning Organization: Fujitsu Technology Solutions GmbH User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: de, de-nds, en, en-US, it MIME-Version: 1.0 To: "ftpext@ietf.org" References: <20100629052221.092623A6A5C@core3.amsl.com>

<4458F933-86BD-4723-BAC4-CE8E8FBA348F@muada.com> In-Reply-To: <4458F933-86BD-4723-BAC4-CE8E8FBA348F@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [ftpext] New Version Notification for draft-bryan-ftp-hash-05 X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Richard.Koenning@ts.fujitsu.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 13:13:15 -0000 Iljitsch van Beijnum wrote: > On 13 jul 2010, at 2:12, Anthony Bryan wrote: >=20 >>from what I understand, your proposal involves potentially more work >>on the server? >=20 >=20 > If the hashes match then the extra check for the size and the small has= h are unnecessary extra work, yes. But you only have to be able to skip h= ashing a multi-GB file once in a while to make up for that. >=20 >=20 >>>Ah, but the question isn't "what's your name" but something that requi= res a rather expensive operation, which is always a nice DoS vector. >=20 >=20 >>I don't get it...either way, the server and client both have to >>perform the expensive operation, right? >=20 >=20 > A malicious client could ask the server for hashes for all files it has= =2E In my scheme, the amount of work done by the server is limited to com= puting the short hash, unless the malicious client has the full file or i= ts full hash, in which case the client can get the server to compute hash= es over the entire files. The malicious client needs only the short hash to get the server into=20 computing the hash of the entire file, because the server recognizes=20 only after doing this, that the client hasn't the correct hash of the=20 complete file. Therefore i don't see the gain of your method regarding=20 DoS attacks. --=20 Dr. Richard W. K=F6nning Fujitsu Technology Solutions GmbH From robmcm@microsoft.com Tue Jul 13 15:01:12 2010 Return-Path: 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 688C33A6A4D for ; Tue, 13 Jul 2010 15:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 LW0r8VH+FirY for ; Tue, 13 Jul 2010 15:01:11 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 6E3B33A6A15 for ; Tue, 13 Jul 2010 15:01:11 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 13 Jul 2010 15:01:19 -0700 Received: from TK5EX14MBXC129.redmond.corp.microsoft.com ([169.254.8.169]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0180.004; Tue, 13 Jul 2010 15:01:18 -0700 From: Robert McMurray To: Anthony Bryan , "ftpext@ietf.org" Thread-Topic: [ftpext] A few comments on draft-bryan-ftp-hash-05 Thread-Index: AQHLIGJRsnqG6pQWMEyywDXSJO7fBZKvYmRg Date: Tue, 13 Jul 2010 22:01:15 +0000 Message-ID: References: <4C2F1B7A.2040707@filezilla-project.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 22:01:12 -0000 In response to the following question that Anthony had posted: >> What should happen if somebody attempts to HASH >> something that isn't a file (e.g. it's a directory)? I have a suggestion - why not return a list of filenames with their associa= ted hashes for the directory using the algorithm that was specified by an e= arlier OPTS command? For example: C> HASH /foo/ S> 125 Data connection already open; transfer starting. S> MD5 F0E1D2C3B4A5968778695A4B3C2D1E0F file1.txt S> MD5 78695A4B3C2D1E0FF0E1D2C3B4A59687 file2.txt S> MD5 0F1E2D3C4B5A69788796A5B4C3D2E1F0 file3.txt S> 226 Transfer complete. This has obvious benefits when considering an FTP client that is trying to = synchronize a list of files between locations, and it's much more reliable = than file sizes and date/time stamps. In addition, allowing for the HASH co= mmand to be requested for a directory would be much better than trying to i= mplement hashes in the response to a LIST request. From tim.kosse@filezilla-project.org Tue Jul 13 15:40:42 2010 Return-Path: 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 7FDE83A6A0D for ; Tue, 13 Jul 2010 15:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 00laiNHkTvhw for ; Tue, 13 Jul 2010 15:40:41 -0700 (PDT) Received: from filezilla-project.org (cl-1464.dus-01.de.sixxs.net [IPv6:2a01:198:200:5b7::2]) by core3.amsl.com (Postfix) with ESMTP id 652EE3A6833 for ; Tue, 13 Jul 2010 15:40:41 -0700 (PDT) Received: from p4fe0c62b.dip.t-dialin.net ([79.224.198.43] helo=[192.168.0.203]) by filezilla-project.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1OYo9e-0002zc-Md; Wed, 14 Jul 2010 00:40:47 +0200 Message-ID: <4C3CEB60.1040903@filezilla-project.org> Date: Wed, 14 Jul 2010 00:40:32 +0200 From: Tim Kosse User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Robert McMurray References: <4C2F1B7A.2040707@filezilla-project.org> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF204E08A7DBBEFFC8BAD0C0C" Cc: "ftpext@ietf.org" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 22:40:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF204E08A7DBBEFFC8BAD0C0C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On 2010-07-14 00:01, Robert McMurray wrote: > why not return a list of filenames with their associated hashes for the= directory [...]? For example: >=20 > C> HASH /foo/ > S> 125 Data connection already open; transfer starting. > S> MD5 F0E1D2C3B4A5968778695A4B3C2D1E0F file1.txt > S> MD5 78695A4B3C2D1E0FF0E1D2C3B4A59687 file2.txt > S> MD5 0F1E2D3C4B5A69788796A5B4C3D2E1F0 file3.txt > S> 226 Transfer complete. Are you proposing to use a data connection just like with RETR/STOR and the likes? If so, how to distinguish between getting the hash for a single file (as sent over the control connection) and getting the hashes for an entire directory? Either all data needs to be sent over the transfer connection or the transfer connection must never be used for HASH, otherwise the client would not know when to send PORT/PASV... in preparation. In case everything goes over the transfer connection, I see a problem with directories containing only a single file with a name identical to that of the directory: > S> MD5 F0E1D2C3B4A5968778695A4B3C2D1E0F file1.txt Is it a file named file1.txt in the current directory or a file named file1.txt in the file1.txt directory? This this getting even more complicated considering that the FTP specs do not mandate a particular path syntax. The other possible solution would be to use a multi-line response. Last but not least, what should happen if the client issues HASH on a directory containing over a million files? Tim --------------enigF204E08A7DBBEFFC8BAD0C0C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw862cACgkQ8N9+lcqiUkXnFwCfRdAf6xkb/+Wiu/kAGQEIOHSv 9+wAn166gxKEWe0erzxISfabw41Wd0B4 =DoBm -----END PGP SIGNATURE----- --------------enigF204E08A7DBBEFFC8BAD0C0C-- From robmcm@microsoft.com Tue Jul 13 17:57:58 2010 Return-Path: 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 058E73A68FD for ; Tue, 13 Jul 2010 17:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 KE2yvAtIX92L for ; Tue, 13 Jul 2010 17:57:57 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id EA24C3A6822 for ; Tue, 13 Jul 2010 17:57:56 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 13 Jul 2010 17:58:06 -0700 Received: from TK5EX14MBXC129.redmond.corp.microsoft.com ([169.254.8.169]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0180.004; Tue, 13 Jul 2010 17:58:05 -0700 From: Robert McMurray To: Tim Kosse Thread-Topic: [ftpext] A few comments on draft-bryan-ftp-hash-05 Thread-Index: AQHLIGJRsnqG6pQWMEyywDXSJO7fBZKvYmRggACK/QD//6UpoA== Date: Wed, 14 Jul 2010 00:57:52 +0000 Message-ID: References: <4C2F1B7A.2040707@filezilla-project.org> <4C3CEB60.1040903@filezilla-project.org> In-Reply-To: <4C3CEB60.1040903@filezilla-project.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ftpext@ietf.org" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 00:57:58 -0000 VGhhbmtzLCBUaW0uDQoNCj4+IHdoeSBub3QgcmV0dXJuIGEgbGlzdCBvZiBmaWxlbmFtZXMgd2l0 aCB0aGVpciBhc3NvY2lhdGVkDQo+PiBoYXNoZXMgZm9yIHRoZSBkaXJlY3Rvcnk/IEZvciBleGFt cGxlOg0KPj4gDQo+PiBDPiBIQVNIIC9mb28vDQo+PiBTPiAxMjUgRGF0YSBjb25uZWN0aW9uIGFs cmVhZHkgb3BlbjsgdHJhbnNmZXIgc3RhcnRpbmcuDQo+PiBTPiBNRDUgRjBFMUQyQzNCNEE1OTY4 Nzc4Njk1QTRCM0MyRDFFMEYgZmlsZTEudHh0DQo+PiBTPiBNRDUgNzg2OTVBNEIzQzJEMUUwRkYw RTFEMkMzQjRBNTk2ODcgZmlsZTIudHh0DQo+PiBTPiBNRDUgMEYxRTJEM0M0QjVBNjk3ODg3OTZB NUI0QzNEMkUxRjAgZmlsZTMudHh0DQo+PiBTPiAyMjYgVHJhbnNmZXIgY29tcGxldGUuDQo+IA0K PiBBcmUgeW91IHByb3Bvc2luZyB0byB1c2UgYSBkYXRhIGNvbm5lY3Rpb24ganVzdCBsaWtlIHdp dGgNCj4gUkVUUi9TVE9SIGFuZCB0aGUgbGlrZXM/IElmIHNvLCBob3cgdG8gZGlzdGluZ3Vpc2gN Cj4gYmV0d2VlbiBnZXR0aW5nIHRoZSBoYXNoIGZvciBhIHNpbmdsZSBmaWxlIChhcyBzZW50IG92 ZXINCj4gdGhlIGNvbnRyb2wgY29ubmVjdGlvbikgYW5kIGdldHRpbmcgdGhlIGhhc2hlcyBmb3Ig YW4NCj4gZW50aXJlIGRpcmVjdG9yeT8NCj4gDQo+IEVpdGhlciBhbGwgZGF0YSBuZWVkcyB0byBi ZSBzZW50IG92ZXIgdGhlIHRyYW5zZmVyDQo+IGNvbm5lY3Rpb24gb3IgdGhlIHRyYW5zZmVyIGNv bm5lY3Rpb24gbXVzdCBuZXZlciBiZSB1c2VkDQo+IGZvciBIQVNILCBvdGhlcndpc2UgdGhlIGNs aWVudCB3b3VsZCBub3Qga25vdyB3aGVuIHRvDQo+IHNlbmQgUE9SVC9QQVNWLi4uIGluIHByZXBh cmF0aW9uLg0KDQpZZXMgLSBJIGFtIHByb3Bvc2luZyB0byB1c2UgdGhlIGRhdGEgY2hhbm5lbC4g SXQncyBzbGlnaHRseSBtb3JlIGV4cGVuc2l2ZSBpbiB0ZXJtcyBvZiByZXNvdXJjZXMgKGUuZy4g b3BlbmluZyB0aGUgZGF0YSBjaGFubmVsKSBidXQgdGhlIHRyYWRlb2ZmIGlzIHdvcnRoIGl0IHdo ZW4gZGVhbGluZyB3aXRoIGxhcmdlIGRpcmVjdG9yaWVzLCB3aGljaCBJJ2xsIGV4cGxhaW4gbGF0 ZXIuDQoNCg0KPiBJbiBjYXNlIGV2ZXJ5dGhpbmcgZ29lcyBvdmVyIHRoZSB0cmFuc2ZlciBjb25u ZWN0aW9uLCBJDQo+IHNlZSBhIHByb2JsZW0gd2l0aCBkaXJlY3RvcmllcyBjb250YWluaW5nIG9u bHkgYSBzaW5nbGUNCj4gZmlsZSB3aXRoIGEgbmFtZSBpZGVudGljYWwgdG8gdGhhdCBvZiB0aGUg ZGlyZWN0b3J5Og0KPiANCj4gUz4gTUQ1IEYwRTFEMkMzQjRBNTk2ODc3ODY5NUE0QjNDMkQxRTBG IGZpbGUxLnR4dA0KPiANCj4gSXMgaXQgYSBmaWxlIG5hbWVkIGZpbGUxLnR4dCBpbiB0aGUgY3Vy cmVudCBkaXJlY3Rvcnkgb3INCj4gYSBmaWxlIG5hbWVkIGZpbGUxLnR4dCBpbiB0aGUgZmlsZTEu dHh0IGRpcmVjdG9yeT8gVGhpcw0KPiB0aGlzIGdldHRpbmcgZXZlbiBtb3JlIGNvbXBsaWNhdGVk IGNvbnNpZGVyaW5nIHRoYXQgdGhlDQo+IEZUUCBzcGVjcyBkbyBub3QgbWFuZGF0ZSBhIHBhcnRp Y3VsYXIgcGF0aCBzeW50YXguDQoNCkkgYW0gc3VnZ2VzdGluZyB0aGUgc2FtZSBiZWhhdmlvciB0 aGF0IHlvdSB3b3VsZCBleHBlY3Qgd2l0aCBhIExJU1QgY29tbWFuZDoNCg0KLSBJZiB5b3Ugc2Vu ZCBMSVNUIG9yIEhBU0ggd2l0aCBubyBwYXJhbWV0ZXJzIHRoZW4gdGhlIHNlcnZlciB3aWxsIGFz c3VtZSB0aGUgY3VycmVudCBkaXJlY3RvcnkuDQotIElmIHlvdSBzZW5kIExJU1Qgb3IgSEFTSCB3 aXRoIGEgc2luZ2xlIHBhcmFtZXRlciBvZiAiZm9vIiB0aGVuIHRoZSBzZXJ2ZXIgZGV0ZXJtaW5l cyBpZiAiZm9vIiBpcyBhIGZpbGUgb3IgYSBzdWJkaXJlY3Rvcnkgb2YgdGhlIGN1cnJlbnQgZGly ZWN0b3J5IGFuZCB0aGVuIHJlc3BvbmRzIGFjY29yZGluZ2x5Lg0KLSBJZiB5b3Ugc2VuZCBMSVNU IG9yIEhBU0ggd2l0aCBhIHNpbmdsZSBwYXJhbWV0ZXIgb2YgIi9mb28vYmFyLyIgdGhlbiB0aGUg c2VydmVyIGtub3dzIHRoYXQgeW91IGFyZSByZXF1ZXN0aW5nIGEgcGF0aCB0aGF0IGlzIGJhc2Vk IG9mZiB0aGUgc2VydmVyJ3Mgcm9vdCBwYXRoIGFuZCByZXNwb25kcyBhY2NvcmRpbmdseS4NCg0K VG8gYW5zd2VyIHlvdXIgcXVlc3Rpb24gbW9yZSBkaXJlY3RseSwgb25seSBmaWxlcyBoYXNoZXMg YXJlIHJldHVybmVkIGluIHRoZSByZXNwb25zZSB0byBhIEhBU0ggY29tbWFuZCwgc28gYSBsaW5l IGluIHRoZSBzZXJ2ZXIgcmVzcG9uc2UgdGhhdCBsaXN0ZWQgIk1ENSBGMEUxRDJDM0I0QTU5Njg3 Nzg2OTVBNEIzQzJEMUUwRiBmaWxlMS50eHQiIHdvdWxkIG1lYW4gYSBmaWxlIG5hbWVkICJmaWxl MS50eHQiIGluIHRoZSBjdXJyZW50IGRpcmVjdG9yeTsgdGhpcyBpcyB0aGUgc2FtZSBhcyBpZiB0 aGUgY2xpZW50IHNlbnQgYSAiTElTVCBmaWxlMS50eHQiIGNvbW1hbmQgdGhhdCB3b3VsZCByZXR1 cm4gdGhlIGRpcmVjdG9yeSBsaXN0aW5nIGZvciB0aGF0IGZpbGUgaW4gdGhlIGN1cnJlbnQgZGly ZWN0b3J5LiBDdXJyZW50bHkgYSBjbGllbnQgaGFzIHRvIGtlZXAgdHJhY2sgb2YgdGhlIGN1cnJl bnQgd29ya2luZyBkaXJlY3Rvcnkgd2hlbiBpdCBzZW5kcyBhIExJU1QgY29tbWFuZCwgYW5kIHRo ZXJlIHdvdWxkIGJlIG5vIGRpZmZlcmVuY2UgZm9yIEhBU0guIFRoZSBMSVNUIGNvbW1hbmQgaGFz IHRoZSBhZGRpdGlvbmFsIG92ZXJoZWFkIG9mIGVudW1lcmF0aW5nIGRpcmVjdG9yaWVzIGluIGEg cmVzcG9uc2UsIGJ1dCBIQVNIIHdvdWxkIGhhdmUgbm8gbmVlZCB0byBkbyB0aGF0LCBzbyB0aGVy ZSBpcyBubyBjb25mdXNpb24gYXMgdG8gd2hldGhlciB0aGUgc2VydmVyIHJlc3BvbnNlIG1lYW50 IGEgZmlsZSBvciBhIGRpcmVjdG9yeS4NCg0KDQo+IFRoZSBvdGhlciBwb3NzaWJsZSBzb2x1dGlv biB3b3VsZCBiZSB0byB1c2UgYSBtdWx0aS1saW5lDQo+IHJlc3BvbnNlLg0KDQpUaGF0IGlzIGNl cnRhaW5seSBhIHBvc3NpYmlsaXR5LCBidXQgSSB3b3VsZCB0aGluayB0aGF0IHRoZSBkYXRhIGNo YW5uZWwgd291bGQgd29yayBiZXR0ZXIuIChBbmQgb25jZSBhZ2FpbiBpdCB3b3VsZCBiZSBjb25z aXN0ZW50IHdpdGggY29tbWFuZHMgbGlrZSBMSVNULikNCg0KDQo+IExhc3QgYnV0IG5vdCBsZWFz dCwgd2hhdCBzaG91bGQgaGFwcGVuIGlmIHRoZSBjbGllbnQgaXNzdWVzDQo+IEhBU0ggb24gYSBk aXJlY3RvcnkgY29udGFpbmluZyBvdmVyIGEgbWlsbGlvbiBmaWxlcz8NCg0KVGhpcyBpcyB3aGVy ZSBpc3N1aW5nIGEgSEFTSCBjb21tYW5kIGZvciBkaXJlY3RvcnkgcmVhbGx5IGhlbHBzIG91dCAt IHlvdSBjdXJyZW50bHkgaGF2ZSB0aGUgc2FtZSBzaXR1YXRpb24gd2l0aCB0aGUgTElTVCBjb21t YW5kLCBtZWFuaW5nIHRoYXQgeW91IGNhbiBpc3N1ZSBhIExJU1QgY29tbWFuZCBmb3IgYSBkaXJl Y3Rvcnkgd2l0aCBhIG1pbGxpb24gZmlsZXMgYW5kIHRoZW4geW91ciBzZXJ2ZXIgaGFzIHRvIHJl c3BvbmQgd2l0aCB0aGF0IGRpcmVjdG9yeSBsaXN0aW5nIC0gdGhlcmUgd291bGQgYmUgbm8gZGlm ZmVyZW5jZSB3aXRoIHRoZSBIQVNIIGNvbW1hbmQsIGV4Y2VwdCBmb3IgdGhlIGFkZGl0aW9uYWwg b3ZlcmhlYWQgZm9yIGNvbXB1dGluZyBoYXNoZXMgaWYgdGhleSBhcmUgbm90IGFscmVhZHkgcHJl LWhhc2hlZCBvciBjYWNoZWQgc29tZWhvdyBieSB0aGUgRlRQIHNlcnZlciBpbXBsZW1lbnRhdGlv bi4gQnV0IHRoaW5rIGFib3V0IHRyeWluZyB0byBzeW5jaHJvbml6ZSBhIGNsaWVudCBhbmQgc2Vy dmVyIHdpdGggYSBtaWxsaW9uIGZpbGVzIC0gdGhlIGNsaWVudCB3aWxsIG5lZWQgdG8gZ2V0IGEg ZGlyZWN0b3J5IGxpc3RpbmcgZnJvbSB0aGUgc2VydmVyIHRvIGdldCB0aGUgbGlzdCBvZiBmaWxl cyB0aGF0IGV4aXN0IGF0IGVhY2ggbG9jYXRpb24sIHRoZW4gaXNzdWUgYSBIQVNIIGNvbW1hbmQg Zm9yIF9ldmVyeV8gZmlsZSBpbmRpdmlkdWFsbHkgKHdoaWNoIGlzIGFuIGVub3Jtb3VzIGFtb3Vu dCBvZiBjbGllbnQvc2VydmVyIHJvdW5kLXRyaXBzKSBpbnN0ZWFkIG9mIGlzc3VpbmcgYSBzaW5n bGUgSEFTSCBjb21tYW5kIGZvciB0aGUgd2hvbGUgZGlyZWN0b3J5Lg0KDQpUaGFua3MgYWdhaW4u DQo= From paulfordh@uk.ibm.com Wed Jul 14 23:47:54 2010 Return-Path: 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 B8F7E3A6937 for ; Wed, 14 Jul 2010 23:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 WL3KyI1Hrvpj for