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

From: John C Klensin <[email-masked]>
Date: Wed, 12 May 2010 17:39:06 -0400

--On Wednesday, 12 May, 2010 17:12 +0100 Alexey Melnikov
<[email-masked]> wrote:

>...
> 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.

Alexey,

While I'd like to see a BOF too, and I suppose that Barry and I
could get a proposal together, I think you and the IESG should
look at this in a different way.

As Paul Hoffman pointed out, there is a large community of FTP
users out there.  There are even multiple people, in multiple
organizations, who spend significant time working on code for
it.  However, while several of them have been willing to write
individual submission drafts, they have not been willing to show
up at the IETF and do work, with each other, to get this
standardized.

For the record, while I agree with Paul, I'd also suggest that,
even if the relevant community were much smaller, it would be
worthwhile to develop a coordinated effort to design and
evaluate FTP modification proposals if only to ensure continued
interoperability.  Others may disagree, but our success record
when we tell people not to do something that works well for them
and, in their opinion, poses no risks, is terrible.  All saying
"FTP is dead, go use something else" can accomplish is to drive
the work away from the IETF.  That increases the risk of
interoperability problems if those who are interested don't find
another forum.  If they do find another forum, it could
strengthen some body who would like to eat our lunch in other
areas, areas that we have not chosen to discard.

However, my view is that there is not, and should not be,
meaningful community consensus for putting any (or all) of these
proposals on the Standards Track unless a coordinated effort is
possible.  If someone from the relevant community needs help
putting a BOF proposal together, I'd be happy to help.  But,
absent signs of willingness, within that community, to
participate actively and take leadership roles, I don't see a
BOF as being helpful.  It might just confirm that there is a
problem (which we know) and that no one is actually willing to
work together rather than writing individual proposals.

So my answer would be that considering these documents in an
uncoordinated way as individual submissions is a bad idea.  The
alternative to a WG (or some coordination alternative) should
not be "well then, we have to process and approve the individual
submissions".  It should be "if the FTP community can't organize
itself sufficiently, even with offers of help, to put a WG (or
other coordination process) together, then IETF review and
value-added is almost meaningless".  If that were to be the
case, those involved should revise their documents into, e.g.,
"Paul's and Robert's clever idea for an FTP extension for
virtual hosts", publish them as Informational, enter the
relevant bits into the registry, and move on.

I'd also suggest that those who don't like FTP and think we
should do no more work on it should not be complaining about
this draft, or others, but should be writing an I-D explaining
their case.  If they can get enough consensus to get that
explanation published as a BCP or standards-track document
moving FTP to Historic, so be it (although I'd be surprised).
If not and their arguments are well-reasoned and documented, I
assume that the ISE would be as welcoming to their contribution
as he would be to well-written protocol descriptions of existing
practices or strongly-motivated proposals.

I think keeping these documents off standards track because
there isn't a critical mass of designers and developers willing
to do work would be a sad outcome.  However, unless the
community of folks proposing these extensions are willing to
come forward and start working with each other in a coordinated
and consensus-establishing way, I think it is by far the better
outcome than more uncoordinated and mutually underdesigned
standards-track extensions.

best,
     john

p.s. I've been trying to avoid saying "a protocol-developing WG
is the only way" although it is certainly my first preference.
Maybe an FTP-specific review team that would contain at least
some appointed experts and that worked entirely by
correspondence would be adequate.  Maybe we could do something
intense in a meeting or two to lay out design principles against
which the individual submissions could then be evaluated.
Maybe you or others can come up with some other idea, even if it
were radical enough to require a 3933 experiment proposal first.
But I think that anything that goes on the standard track has to
reflect IETF value-added and some reasonable level of informed
IETF consensus that the idea is a good one, both individually
and in context.  And, right now, this document doesn't meet
those criteria.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 12 May 2010 16:04:04 -0700

On 5/12/10 2:39 PM, John C Klensin wrote:
>  Others may disagree, but our success record when we tell people not
>  to do something that works well for them and, in their opinion, poses
>  no risks, is terrible.  All saying "FTP is dead, go use something
>  else" can accomplish is to drive the work away from the IETF.

In this case, the IETF should say "Use something more secure."  The 
proposed enhancement combines multiple host's credentials to avoid 
transparent techniques that could offer network isolation as well.  Your 
concern would be valid when there is also a commensurate effort at 
improving security.  Unfortunately, the opposite is true.

-Doug

---

From: John C Klensin <[email-masked]>
Date: Thu, 13 May 2010 00:34:40 -0400

--On Wednesday, 12 May, 2010 16:04 -0700 Douglas Otis
<[email-masked]> wrote:

>...
> In this case, the IETF should say "Use something more secure."
> The proposed enhancement combines multiple host's credentials
> to avoid transparent techniques that could offer network
> isolation as well.  Your concern would be valid when there is
> also a commensurate effort at improving security.
> Unfortunately, the opposite is true.

Doug,

Let's separate two issues.  One is whether or not this
particular proposal, with or without RFC 4217 (an existing
Proposed Standard), is appropriate.  If it is not, or cannot
exist in harmony with 4217, then it reinforces my view that it
should not be put on the Standards Track without a more
comprehensive examination in the context of existing FTP work
and proposals.

The other is whether we should proceed with any FTP work at all.
Especially in the context of 4217 (you were aware of that when
you wrote your comments, weren't you), I find your remarks
completely unpersuasive.  One could reasonably argue that it is
time to establish a SASL binding for FTP (maybe it is; a WG
could figure that out), but I think it is hard to argue that FTP
generally is any worse from an authentication, authorization, or
privacy standpoint than any other protocol that we've protected
by running it over an encrypted tunnel.  YMMD, of course.

     john

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 13 May 2010 10:15:29 -0500

I would like to chime in on this aspect of John's note...

> practices or strongly-motivated proposals.

As a new IAB member, I'm becoming disturbed about the number of things that 
I'm tripping over that "everyone knows", but we haven't written down yet. 
The list of reasons we need to punt FTP seems to be one of those things that 
we should be capturing as part of our institutional memory.

I would be willing to support a document like this in the IAB stream, if 
that were appropriate, but even if it's not, I think such a document would 
be a classic example of the reason we need, and have, an Independent Stream. 
It should find a home.

Thanks,

Spencer

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 13 May 2010 08:26:32 -0700

At 10:15 AM -0500 5/13/10, Spencer Dawkins wrote:
>As a new IAB member, I'm becoming disturbed about the number of things that I'm tripping over that "everyone knows", but we haven't written down yet. The list of reasons we need to punt FTP seems to be one of those things that we should be capturing as part of our institutional memory.
>
>I would be willing to support a document like this in the IAB stream, if that were appropriate, but even if it's not, I think such a document would be a classic example of the reason we need, and have, an Independent Stream. It should find a home.

Many people pay attention to the authors of RFCs. An RFC saying "Foo considered bad" with the IAB as the authors carries much more weight than one from Some Guy, as well it should.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 13 May 2010 10:41:37 -0500

Hi, Paul,

>>As a new IAB member, I'm becoming disturbed about the number of things 
>>that I'm tripping over that "everyone knows", but we haven't written down 
>>yet. The list of reasons we need to punt FTP seems to be one of those 
>>things that we should be capturing as part of our institutional memory.
>>
>>be a classic example of the reason we need, and have, an Independent 
>>Stream. It should find a home.
>
> Many people pay attention to the authors of RFCs. An RFC saying "Foo 
> considered bad" with the IAB as the authors carries much more weight than 
> one from Some Guy, as well it should.

Sure. John's food chain started with proposed standard/BCP, which should 
carry some weight as well :-)

Your point was that the stream matters. I would agree.

My point was that this should not be one of the documents that we can't find 
a place to publish.

Thanks,

Spencer

---

From: Douglas Otis <[email-masked]>
Date: Thu, 13 May 2010 17:44:04 -0700

> comprehensive examination in the context of existing FTP work
This draft describes server side validations, while leaving open host 
name compliance with x.509 distinguished names, and limits input to 
Puny-code rather than UTF-8 as specified by RFC3280.  Should people be 
expected to input ACE-labels or make UTF-8/ACE-label conversions in both 
directions?  In addition, there remains many insecure implementations of 
FTP without also introducing these changes.  Use of FTPS, as suggested, 
is not normally part of any pre-configured FTP offering.  FTP also 
remains problematic as implemented in many browsers, where of course 
this proposed virtual host FTP is likely attractive.

Section 3.1 states:

.---
[The HOST input] should normally be the same host name
that was used to obtain the IP address to which the FTP control
connection was made, after any client conversions have been completed
that convert an abbreviated or local alias to a complete (fully
qualified) domain name, but before resolving a DNS alias (owner of a
CNAME resource record) to its canonical name.

Internationalization of domain names is only supported through the use of
Puny-code as described in RFC3492.
'---

Does this meet a reasonable expectations for IDN support?  Many local name services do not use Puny-code, but use of UTF-8 instead.

> by running it over an encrypted tunnel.  YMMD, of course.
The scant coverage of client related compliance suggests there is 
little interest in seeing security improved.  The crude introduction of 
host names makes security related efforts more difficult to resolve.  In 
the meantime, FTP continues to represent a security hazard, despite 
IETF's efforts.  This draft, in its current form, is unlikely to bring a 
positive change in security.  As such, it seems right to discourage 
changes that might interfere with efforts at achieving better 
implementations.  I share others doubts that further efforts such as 
this will lead to improve security, but instead lend false impressions.

-Doug