Subject: Re: Last Call: draft-hethmon-mcmurray-ftp-hosts (File Transfer Protocol HOST Command) to Proposed Standard

From: John C Klensin <[email-masked]>
Date: Mon, 10 May 2010 11:22:52 -0400

--On Monday, 12 April, 2010 12:44 -0700 The IESG
<[email-masked]> wrote:

> The IESG has received a request from an individual submitter
> to consider  the following document:
> 
> - 'File Transfer Protocol HOST Command '
>    <draft-hethmon-mcmurray-ftp-hosts-11.txt> as a Proposed
> Standard
>...

IESG,

This draft is much improved from prior versions, and the
explanations of why adding a new, pre-authentication, command
is needed are appreciated.  There are other possibilities,
however, that do not increase the number of turnarounds or add
to the complexity of the command.   For example, one could
either create some syntax within the USER command if the
extension were advertised so that one would have 
     USER userid virtual-host-id
     PASS ...
     ACCT ...
(possibly with some other delimiter) or one could, with such
an option, replace USER entirely, e.g., 
     UHST userid virtual-host-id
     etc.

This leads to a more general point, which I think is the main
issue with this and the other FTP proposals that are at various
points in the pipe.  FTP is our oldest applications protocol
that is still in active use.  It was rather carefully designed.
It is not HTTP and retrofitting HTTP syntax and concepts into
it is not obviously the right thing to do.    

If we are going to start adding features to FTP, it seems to me
that we need a strategy and to make design decisions: lots of
little commands with four-letter names and single-token syntax
versus a smaller number of more complex commands versus
extending (or, in the words of the authors, "overloading")
existing commands.  Those decisions should not -- cannot -- be
made by processing one command extension at a time, with each
one reflecting the taste and assumptions of its authors in
different ways.

It seems to me that we need a WG or some other mechanism for
establishing and determining community consensus around basic
design principles for FTP extensions.  If the IESG then wants
to process individual extensions as individual submissions,
that would be fine, but let's first at least establish a
framework for evaluating them.

   thanks,
     john

---

From: Barry Leiba <[email-masked]>
Date: Wed, 12 May 2010 09:28:50 -0400

>>    <draft-hethmon-mcmurray-ftp-hosts-11.txt> as a Proposed

I agree with John Klensin's comments, and especially want to call out this part:

On Mon, May 10, 2010 at 11:22 AM, John C Klensin <[email-masked]> wrote:
> Those decisions should not -- cannot -- be

It would be a mistake to build a further array of individual,
uncoordinated extensions to FTP.  As with the establishment of the
imapext, sieve, and morg working groups, when the IETF has seen a
collection or succession of proposals aimed at extending a protocol,
it has opted to charter a working group to coordinate those proposals,
winnow them, and establish community consensus on which to
standardize, and how.

It should do that here, as well.

Barry Leiba

---

From: Joe Abley <[email-masked]>
Date: Wed, 12 May 2010 11:44:20 -0400

On 2010-05-12, at 09:28, Barry Leiba wrote:

> uncoordinated extensions to FTP.

I'm actually slightly surprised that anybody is considering enhancements to FTP in 2010.

I would have thought that given standardised alternatives which are kinder to firewalls and more secure the logical next step would be to publish guidance that advises against using FTP, outlines the reasons why, and points people towards more suitable protocols. Unless I'm missing some use-case where FTP is actually superior to (say) HTTP, or SSH/SFTP?

Joe

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 12 May 2010 17:12:45 +0100

>It should do that here, as well.
Barry/John,
You already know that I am waiting for the FTP BOF proposal for Maastricht.
I can delay asking IESG to review this document till after the BOF, but 
if there is no BOF or nothing comes out of it, I don't think it is fair 
to delay the document just because something can be done better in a WG.

Alexey, as the sponsoring Apps AD.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 12 May 2010 09:32:13 -0700

>I would have thought that given standardised alternatives which are kinder to firewalls and more secure the logical next step would be to publish guidance that advises against using FTP, outlines th…

The use of FTP dwarfs the use of SFTP by at least two orders of magnitude. Further, and more troubling, is that there are few if any SFTP servers that have the same access properties as those common in most FTP servers, namely that the user who connects can *only* see the contents of the home directory and below. (Yes, you can sometimes set up SSH/SFTP with this restriction; doing so is still cumbersome and not well supported on many OSs.)

The use case for FTP remains "password protected access to a limited set of files where eavesdropping on the password or transferred file contents will not cause much damage". As SFTP implementations mature, we might consider suggesting moving away from FTP, but probably not before then.

--Paul Hoffman, Director
--VPN Consortium

---

From: Joe Abley <[email-masked]>
Date: Wed, 12 May 2010 12:38:25 -0400

On 2010-05-12, at 12:32, Paul Hoffman wrote:

> The use of FTP dwarfs the use of SFTP by at least two orders of magnitude.

Sure.

To paraphrase my comment (or at least re-state it in a clearer way) from a protocol perspective, setting aside deficiencies in particular implementations, it seems more apropos to convey the message that FTP is inadequate in various ways, and to point towards some alternatives, than to imply (through the appearance of protocol maintenance) that FTP is alive and well and a good choice of protocol for new applications.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Wed, 12 May 2010 14:46:08 -0400 (EDT)

> I would have thought that given standardised alternatives which are kinder to firewalls and more secure the logical next step would be to publish guidance that advises against using FTP, outlines t…

Agreed. It is irresponsible to patch up the ftp protocol to enhance its life span.

Paul

---

From: Douglas Otis <[email-masked]>
Date: Wed, 12 May 2010 11:47:25 -0700

> To paraphrase my comment (or at least re-state it in a clearer way) from a protocol perspective, setting aside deficiencies in particular implementations, it seems more apropos to convey the messag…
Agreed.  Use of plain-text authentication, even with a pretext of 
restricting directory views, lacks merit.   Most operating systems 
enforce directory access without dependence upon the access application. 
   Suggestions, that in effect recommends FTP to maintain security, 
would be misleading especially with many outstanding exploits still 
found in clients and browsers.

-Doug