Re: [ftpext] WG Status (was: Re: Fwd: Re: ftpext2 review of FTP HOST command?)

John C Klensin <john-ietf@jck.com> Tue, 13 March 2012 14:10 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ftpext@ietfa.amsl.com
Delivered-To: ftpext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CB321F8880 for <ftpext@ietfa.amsl.com>; Tue, 13 Mar 2012 07:10:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.762
X-Spam-Level:
X-Spam-Status: No, score=-102.762 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Dx2k5SMewe3 for <ftpext@ietfa.amsl.com>; Tue, 13 Mar 2012 07:10:28 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id C23A021F887F for <ftpext@ietf.org>; Tue, 13 Mar 2012 07:10:28 -0700 (PDT)
Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1S7SM7-000N5c-Dx; Tue, 13 Mar 2012 10:05:39 -0400
Date: Tue, 13 Mar 2012 10:10:20 -0400
From: John C Klensin <john-ietf@jck.com>
To: Daniel Stenberg <daniel@haxx.se>
Message-ID: <25D7B5EC576CA65951F75AB8@PST.JCK.COM>
In-Reply-To: <alpine.DEB.2.00.1203121734130.18227@tvnag.unkk.fr>
References: <8CC6BE90-16F4-41DB-835B-B8BC9722156A@frobbit.se> <4F5E0B4F.2080401@att.com> <8050883FA9D9EB809D8E848C@PST.JCK.COM> <alpine.DEB.2.00.1203121734130.18227@tvnag.unkk.fr>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: ftpext@ietf.org
Subject: Re: [ftpext] WG Status (was: Re: Fwd: Re: ftpext2 review of FTP HOST command?)
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 13 Mar 2012 14:10:30 -0000

--On Tuesday, March 13, 2012 08:32 +0100 Daniel Stenberg
<daniel@haxx.se> wrote:

>> If the answer to some or all of the above is "no", should
>> people really  spend time reviewing this document or should
>> we be thinking about concluding  that FTP's detractors are
>> correct about level of interest and hence give up  on this
>> effort?
> 
> I'm sorry to agree: this is not a very functional WG. To me,
> it looks like there's not enough interest from implementors to
> update FTP.

Let me say something slightly more optimistic than the above,
even though I don't think it helps the WG very much.  I think we
have several implementers out there, each with a client/customer
base.  While those clusters of customers probably overlap enough
in their properties and needs to be different from a
niche-per-implementer/ vendor, they are different.  The result
is that vendor X wants extensions A, B, and C (which they may
have developed, implemented, and deployed in some form).  Vendor
Y wants extensions D, E, and C', where C' is functionally more
or less like C but not identical.  Maybe we could get them
together to work on a common C-approximation (although there
hasn't been evidence of that so far).  But X sees no commercial
value in working on, or even reviewing D or E and Y sees no
commercial value in working on A or B.  

Worse from our point of view, X's main interest, as a server
vendor, in bringing A and B to the IETF is to get them
standardized so they can beat up client vendors who haven't
implemented what would otherwise be a perfectly good proprietary
feature.  That not only gives them no incentive to invest energy
on D or E, it gives them significant incentive to push back on
any changes to their already-implemented versions of A and B
(using "running code" as an excuse).

I think (Anthony can correct me if needed) we can understand the
target audience for HOST in that context.  While it is one that
might occasionally require strong user authentication (including
the usual cryptographic isolation of the relevant information
and/or handshaking), and might require integrity protection of
the data stream (and that is where draft-ietf-ftpext2-hash comes
in) it would rarely require privacy protection.  I say
"occasionally" because there would be many cases where the
approach would be used anonymously or with a minimum of
identification (just like "normal" FTP).   In that sense, the
model is very similar to web pages that are accessed to retrieve
information rather that, e.g., to carry out transactions that
might require authentication and/or transmission of sensitive
information.

If that is the model, then the proposal in this spec is
reasonable and most of the concern about TLS, especially TLS
with strong certificate-based protection, is largely irrelevant.
However, that view raises the obvious and usual questions:

	(1) Will (and should) the IETF accept a proposal with
	known security weaknesses if the author says "just don't
	use it in contexts requiring strong data privacy
	protection".  
	
	(ii) Are the WG and the IETF willing to accept an FTP
	Extension spec that doesn't play well with extant
	extensions?  The charter is remarkably silent on that
	matter.
	
	(iii) What value can/does the IETF add in this type of
	limited scenario case?
	
	(iv) Why doesn't the specification describe the usage
	scenarios clearly enough that it can clearly exclude
	those cases that require strong security?   
	
Pragmatically, what this all amounts to, IMO, is "draft needs
work".  And the evidence remains that the WG doesn't have
whatever it takes to get that work done.

     john

p.s. On looking at the charter, I discovered that one of the
things the WG committed to do was 

	"* Review and confirm or reject errata of current FTP
	RFCs"

Circa 18 months after we got serious about chartering the group
(longer than that if one uses other criteria), that task hasn't
been started.  Another entry in the "not a good sign" list, IMO.