On Sun, Jun 23, 2002 at 11:04:16PM -0400, Perry E. Metzger wrote:
> 
> "Steven M. Bellovin" <smb@research.att.com> writes:
> > In message <87it49lhu0.fsf@snark.piermont.com>, "Perry E. Metzger" writes:
> > >I'm not sure I was even aware of that RFC before now. Are we sure the
> > >IETF still considers it to be a standards track document? I'd also
> > >suggest that the matter be discussed on tech-security -- tech-userlevel
> > >is not the right list...
> > 
> > It's still listed as "Proposed Standard" in the index.
> 
> Yah, but it has never gotten past Proposed to Draft, and I'm unaware
> of implementations.  At the time it was written, the world was very
> different, and rolling (mostly) your own security transport was
> common. Now everyone Just Uses SSL.

SSL is (surprisingly enough) like the web.  It's not designed for the
uses to which it's been put.  Wake me when SSL can do a reasonable job
of authentication, and isn't just for encryption.  You might have
convinced me if you said "SASL" instead of SSL, but SASL doesn't deal
well with FTP's concept of separate command and data connections.

> The question in my mind is, given
> the utter lack of implementations, do we want something where we've
> got a whole new protocol with potential holes, or do we Just Use SSL
> so we can piggy back on its properties?

There are at least two existing implementations: MIT and Heimdal krb5
distributions come with a ftp that supports rfc2228 (and my changes
to ftpd are based on the Heimdal distribution).  ISTR that Fetch
on the MacOS also supported it...  It should be possible to use SSL
in addition to rfc2228.  SSL in ftpd actually looks like it's built
on top of rfc2228, though I admit some small changes would be necessary
in my code to support it properly.

--aidan