[ftpext] 1st post; miscellaneous FTP additions.
"Alun Jones" <alun@wftpd.com> Sat, 06 November 2010 21:48 UTC
Return-Path: <alun@texis.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 808613A687C for <ftpext@core3.amsl.com>; Sat, 6 Nov 2010 14:48:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.598
X-Spam-Level:
X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=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 8yh+QtqjFk3e for <ftpext@core3.amsl.com>; Sat, 6 Nov 2010 14:47:52 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 7554A3A68D1 for <ftpext@ietf.org>; Sat, 6 Nov 2010 14:47:52 -0700 (PDT)
Received: from Parnassus (c-76-22-68-139.hsd1.wa.comcast.net [76.22.68.139]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MN23M-1PCekv0Na4-006wsH; Sat, 06 Nov 2010 17:48:06 -0400
From: Alun Jones <alun@wftpd.com>
Sender: Alun Jones <alun@texis.com>
To: ftpext@ietf.org
Date: Sat, 06 Nov 2010 14:48:03 -0700
Organization: Texas Imperial Software
Message-ID: <058201cb7dfc$4bd03d00$e370b700$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0583_01CB7DC1.9F716500"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Act978W85xf5b2CRTTaUmeVMZOObkA==
Content-Language: en-us
X-Provags-ID: V02:K0:X7AGKCaoSeWn5d77QSq7BK3/S1r/mwjUSHBepic3cdQ 0Vq88GZ9UrlHdr1xbQjlq7KDM+2ZOdbeoIhW163zDcBbe4oIRH nlZFw9XUXgoJXyK4YC1Un2WIr8+6XwW9LYMSgNxXC3ZuOT4q8B mrpfBjfeaVpjXYZV/TLchAUivJMHwlFhT9ReBPnEHdFvPdtJLi kgiohIL5BY8imnzqcf6nA==
Subject: [ftpext] 1st post; miscellaneous FTP additions.
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: alun@texis.com
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: Sat, 06 Nov 2010 21:48:02 -0000
First, thanks to everyone here for starting up another FTP extensions Working Group. I enjoyed the last one and look forward to hearing much more on the ways we can move FTP forward. Having read the mailing list archives to date, here are a relatively random list of observations: 1. I found this mailing list through a rather random reading of the IETF mailing list. Pure chance. Should this WG perhaps reach out to members of the previous WG's mailing list to let them know that there is a new WG to which they might wish to subscribe? [Or was there an announcement that I simply missed?] 2. I would very much like to see us address not only new and interesting features, but some of the issues that cause enterprises to avoid using FTP. Particularly, I note that there's a perception that FTP is unsecure, that it's not standard (peculiarly enough, SFTP is given as the standard alternative, despite not actually having any standards documentation), that it's inefficient (not sure what is meant by that), that it requires massive firewall holes, and that it frequently fails through firewalls even if you think you have the right holes open. To that end: a. I would like to suggest the use of MODE B with the default data port as common practice. In the absence of errors in communication, or client-requested aborts, this works well through existing firewalls, as well as with TLS, is portable to IPv6, has been a standard since at least RFC 959 days, and only requires that clients request and support MODE B as an option. Some steps to improve this would include: i. Document how MODE B should recover from client-requested aborts, even if the recovery is simply "close all connections and try again". ii. Augment MODE B - for instance, specify options to state that TYPE I, STRU F, can avoid sending REST markers in the data stream. b. Where port assignments are made, use random port assignments as specified in the recent BCP draft http://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-randomization/ to improve protection against port guessing. Are there any standard protocols to use to open firewall holes in relation to existing traffic? UPnP springs to mind, but if there are any other protocols we could use as FTP server / client authors to open these ports (or avoid having to), it is important that we document the use of these for FTP. c. To address storage security of transferred files, it may be appropriate to add commands and responses for the following cases: i. Client requests that server receive next STOR / STOU as sensitive file, and stores it in encrypted storage (with affirmative response if it can do this) ii. Server refuses to send file in response to RETR until client asserts that it will be storing it in encrypted storage. 3. It was suggested earlier in the mailing list that a command be provided for encrypting passwords in transit in some way. While I agree with the general sentiment that TLS should be used for such cases (because the password is generally only sensitive because of the data it protects, and therefore the commands and data should be encrypted and integrity-protected also), there is, or was, a standard for SASL passwords in FTP - I simply can't find it right now. 4. Keeping firewalls open through long data transfers can adequately be achieved using the NOOP command at regular intervals, or if that command is not supported, the STAT command, which is already documented to give a user-readable status during a data transfer. 5. GSSAPI FTP as defined in RFC 2228 should be deprecated, as it does not provide for separate encryption contexts between the command and data ports - because they share an encryption context, if a command is sent during a transfer, the synchronization is lost, and all further data and commands are garbled and unreadable. 6. FTP URIs don't work as documented. I have yet to see a single client implementation that treats "ftp://example.com/foo" as an invitation to connect to example.com and issue the "CWD foo" command - they all issue "CWD /foo". Clinging to ancient documentation that is always ignored seems to be a waste of time. Deprecate the old behaviour, and as crappy as it may be, adopt and accept the behaviour that "all paths are from the root unless they begin with a dot. (ftp://example.com/./foo)" Well, that's enough to be getting on with - let me know if any of these ideas are worth considering, or should be discarded immediately. Thanks again for setting this list up, Alun Jones [Author, WFTPD and WFTPD Pro - http://www.wftpd.com]
- [ftpext] 1st post; miscellaneous FTP additions. Alun Jones
- Re: [ftpext] 1st post; miscellaneous FTP addition… Daniel Stenberg
- Re: [ftpext] 1st post; miscellaneous FTP addition… Anthony Bryan