Hi Brian,
Hi Valery,
Good points, all.
Devil's advocate position: why not deprecate FTP for all deployments where
security is at all important? Its design does not lend itself to
operation without cleartext, and at the moment I can't think of an
application for FTP for which there are not deployed and tested
alternatives (e.g. scp, https) without the ports-in-cleartext drawback.
Now, deprecating a protocol won't make it disappear, but we can
certainly put a big warning sticker on it: "does not work with tcpinc,
here are alternatives that do."
Seems to me that any attempt to solve this with protocol design (your
points 4, 5, 6) will replace one set of brittle corner cases with a
more complex set of brittle corner cases. Best to admit it FTP doesn't
work in an opportunistic-security* world and move on.
I don't think it is so easy in real life. True, there are alternatives to
ftp, but
sometimes end user is unable to use them. For example, if some of
your favourite software gets updates via FTP, than you will face
a dilemma: either don't use tcpinc or don't update these software
(and wait untill its vendor swithes to some different protocol).
I don't know what you will chose. If this software is critical
for you then you will probably get rid of tcpinc. All these cases
will definitely slow down tcpinc deployment.
Regards,
Valery.
Cheers,
Brian
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
