Actually, we should move TELNET to HISTORIC.
Yes, I do use it on occasion to test SMTP. And each time I do that, I have to install a TELNET client. Windows nixed their TELNET client a decade ago, so I tried the Linux box and it was gone there. I recently bid rather a lot of money to buy a rather large 78 record player but I wouldn't say it wasn't obsolete. I was the underbidder on two rather expensive broken cipher machines as well. Not had much luck in that area recently.
I would be very surprised if any UNIX build ships with a Telnet server enabled.
The only thing still using it would be FTP because FTP is layered on TELNET but on a different port. Oh and guess how I know...
Move both to HISTORIC. Saying something is obsolete lets the new stuff arrive to replace it.
On Wed, Jul 10, 2024 at 1:08 PM John C Klensin <john-ietf@xxxxxxx> wrote:
--On Friday, July 5, 2024 08:42 +0000 "Rob Wilton (rwilton)"
<rwilton=40cisco.com@xxxxxxxxxxxxxx> wrote:
> Hi John,
>
> Normally, if I want to share a file with someone, I would encrypt
> it (if necessary) and share it via an online cloud storage provider
> or scp if in a Linux environment. I can't see how this is harder
> than setting up an FTP server and ensuring that the recipient can
> find an ftp client, or how FTP could be deemed to be the most
> secure way of achieving this.
For most purposes and users, it probably is not. From a security
standpoint, it sort of depends on what one cares about and how much.
Do you trust the cloud provider, its security mechanisms, etc., more
than you trust what can be provided locally? If one cares about
records of who is accessing which files, are they more concerned
about the cloud provider's mechanisms and staff or about the
possibility of someone compromising ISPs and intercepting and
interpreting the traffic? If neither party cares whether opponents
or would be attackers know that Y is a client of X (or have some
other relationship) that changes the security/privacy equation as
well. It is important to remember that most decisions about using
are typically insensitive to whatever we might believe about what
sorts of behavior we would consider rational or optimal (even if we
could agree); they are only about what those users or user groups
believe.
Relative to my comments about an FTP user community, another piece of
the puzzle is that their exchanges are typically not about some
semi-random Alice wanting to get a single file to an equally random
Bob. They are about established relationships in which multiple
files will be transferred over time and in both directions. In their
situations, no one is sending credentials by email or relying on some
flavor of opportunistic encryption so weakness in those mechanisms
are irrelevant. I have not dug into many of the cases, but in at
least a few, the process starts with in-person contacts in which USB
sticks with credentials (and, if necessary, software) can be passed
from hand to hand or, perhaps, put in the post with some sort of
tamper-evident packaging. Whatever we might think of it, some of
those folks also believe that using telephones to exchange
information like keys or other security credentials is far safer than
anything that they believe involves the Internet. And, again, it is
not about what we know (or claim we do), only about what they they
believe.
> I still believe that for most users on the Internet, for the vast
> majority of cases, FTP is no longer the best answer for sharing
> files. This is why I believe that IETF making it historic would
> arguably be the right thing to do. I think that I probably stopped
> using it about 10+ years ago and haven't missed it.
Even if I agree about the "no longer the best answer" conclusion (for
"most users" and "majority of cases", I probably do). I can't get to
making it historic... at least unless we define "historic" as "the
IETF no longer cares about it". Otherwise, I'd like to reserve
"historic" for protocols for which there are no longer any active
users or uses; which will simply not work on the contemporary
Internet; or for which there is very broad (not just rough) consensus
that they been superceded by other work with either equivalent or
superset functionality. The "not work" criteria do not include our
opinions about how much security and/or privacy people should want or
need.
As an exercise, would you encourage moving TELNET to Historic
(presumably bringing all of the work on environments, authentication,
and encryption done in the 1990s and early 2000s along with it) or
deprecating it for general use? For most users and the vast
majority of cases, it has been superceded by SSH. The only major uses
I'm aware of (and I'm one of the users) lie in simulating protocols
like SMTP and HTTP for debugging purposes and for running scripts
that provide more FTP functionality than is easily captured in a
fairly simple, single-flle or wildcard, URI. Or, picking up on your
comment below, do we need a BOF about Telnet++?
> I do agree to the point about sharing files over various HTTP based
> services being bespoke. Perhaps someone should plan a BOF to do an
> FTP++ (whatever that looks like) to try and bring file sharing in
> to the 21st century and have a common solution?
This is where my pessimism overcomes my desires and inclination. I
see so much hostility toward FTP that I think such a BOF would
rapidly deteriorate into claims that the work is useless because the
web is better in any possible respect than FTP or any plausible
offspring. I don't know if I would expect more or less hostility if
it were to include one or more of scp, sftp, or even rsync into the
space of "should be a common solution" but that would not help with
having a productive BOF either. In addition, such a BOF would be a
waste of time unless there were an AD who would be willing to take
the work on and form a WG if the BOF recommended that and an IESG
that would be willing to take FTP-derived work seriously. At the
risk of a segue into another recent controversial discussion, would
the IESG be willing to back a BOF or WG chair or list administrator
who started kicking people out who did nothing but repeat themselves
about how much better it would be to do things over the web and/or
cloud. I don't see any, much less all, of those conditions being
met.
Maybe the IETF could do better for the Internet and FTP and other
pre-web application protocols, including the development of 21st
century derivations, by explicitly declaring disinterest and thereby
encouraging the development of an Old Protocols Consortium to look
after them. Even then, I would not predict adoption by most of the
active FTP users I'm seeing. I think an old adage from what we now
call the UI/UX community might apply: "what you already know is
better". I.e., don't expect us to learn new stuff when what we have
been using meets our perceived needs.
If I believed in FTP++ and the IETF, I'd put together an I-D
discussing the strengths and weaknesses of FTP and possibly
approaches that might remedy some of the latter. Then I'd see what
sort of response I got and if it could be used as a foundation for
the BOF you suggest. If nothing else, I think the odds of getting
such a BOF would be much better if there were a starting point
document. I wouldn't have time even if I were less pessimistic.
Dave? Keith? others?
best,
john
>
> Regards,
> Rob
