On 5/12/10 9:34 PM, John C Klensin wrote:
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.
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.
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.
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf