Subject: Ftp-WG: Moderation?

From: [email-masked]
Date: Fri, 6 Oct 2000 11:54:25 -0500

>> Is it ever going to work "how it should work", or is it more likely
that
>> the "how it works today" will be the way it'll always work?  I guess
what
>> I'm asking is whether this will create unnecessary confusion,
publishing
>> two somewhat contradictory RFCs, leading one to suspect that the
Standards
>> Track version is the one new developers should comply with, but turning
out
>> that everyone uses the Informational one?

>I think I agree with what I this Alun is saying here: one or the other,
>please, but not both.
>From what I've seen "how it works today" is best summed up by saying "not
>very well".  If you feel the best-current-practice should be documented,
do
>that in the introductory section, make it clear the discussion is an
>analysis of why it doesn't do what's required, and leave it at that.

Hmmm - To be honest I think current implementations of secure FTP follow
somthing like this:

a) use an ssl tunnel on the control connection - data goes unencrypted
b) listen on 990 and do the ssl immediately upon connection - implicitly
protect the data connection
c) use the AUTH SSL command to start SSL negotiation on the control and
implicitly protect the data
d) use the AUTH TLS command to start SSL on the Control and use PBSZ 0;
PROT P to protect the data.

a) is pathethic, b) is outmoded and broken, c) is used by a few
implementations, particularly the pioneering stuff done by Tim Hudson for
the SSLeay work and d) is the way most new implementation I have seen seem
to go (good on them).

Currently the draft indicates how b), c) and d) should work and explains
how they are not mutually exclusive, despite b) and c) being in direct
conflict with 2228.  I think there is some value in that discussion being
documented.  I also think that the draft is confusing in that it doesn't
contain a single implementation path.  Therefore I feel there is a need to
publish two.  This is the exact model that http has gone down and I think
there is good reason to follow their precedent.  For those of you familiar
with the draft, I propose to leave all the discussion stuff and the timing
diagram stuff (which should have been in 959 in the first place) in the
Informational draft and put the bare bones of the AUTH TLS, PBSZ and PROT
comands into a small simple Standards track document that is easy to
follow and implement.

Paul

--
Paul Ford-Hutchinson :  eCommerce application security :
[email-masked]
MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5YR +44 (0)1926
462005