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

[John C Klensin <[e-mail]>]

--On Tuesday, March 13, 2012 08:32 +0100 Daniel Stenberg
<[e-mail]> 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.