Subject: Re: Two FTP issues

From: "Salz, Rich" <[email-masked]>
Date: Tue, 1 Dec 2020 13:51:03 +0000

*   At least with FTP, it was a choice (ASCII vs binary).

As it is with HTTP, which offers more MIME types.  But requires a properly configured server.

---

From: Larry Masinter <[email-masked]>
Date: Tue, 1 Dec 2020 07:27:33 -0800

At the time FTP was developed, PDP-10s with 9-bit bytes and IBM mainframes
using EBCDIC were common, disk space was limited, and transfer with format
conversion was necessary.
-- 
https://LarryMasinter.net  https://interlisp.org

---

From: "John Levine" <[email-masked]>
Date: 1 Dec 2020 17:22:03 -0000

In article <[email-masked]>,
Joseph Touch  <[email-masked]> wrote:
>Conversion can be useful. I can FTP a text file of Perl and run it just fine on different platforms.
>
>Doing the same with HTTP either requires explicitly excising the surrounding HTML or doing CRLF conversion - still.

Uh, no. Perl, like any other language implemented in this millenium,
deals perfectly well with \n or \r\n line endings on any platform. Try
it if you don't believe me.

As Carsten said, trying to fix up line endings on the fly causes more
problems that it solves which is why no modern protocol tries to do it.
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Keith Moore <[email-masked]>
Date: Tue, 1 Dec 2020 12:52:43 -0500

> problems that it solves which is why no modern protocol tries to do it.

The reason no "modern" protocol tries to do format conversion is that 
the computing industry has more-or-less standardized on a "paper tape" 
model of files being streams of octets, as opposed to the "punched card" 
model of files consisting of fixed or variable-length "records" where 
the file system and operating system deal with those records 
explicitly.   There are efficiency advantages to the latter -  the 
record size or an upper bound for that size is generally known before 
you read the next record, so you never have to handle a record that 
needs an arbitrarily long read buffer - but from an evolutionary 
perspective the paper tape model seems to have won (for now).

In addition, there have been enough exchanges between "paper tape" 
systems with different styles of line ending (CR, LF, or CR LF) that by 
now many tools that deal with text - editors, compilers, interpreters, 
etc.-  just deal with whatever kinds of line endings they find.    
That's a relatively recent change, and it didn't happen all at once.   
But these days conversion during file transfer is necessary less often 
than it once was.    The differences in format do still cause problems, 
though, so a truly reliable automatic format conversion would be a 
blessing, IMO.

Keith

---

From: John C Klensin <[email-masked]>
Date: Tue, 01 Dec 2020 13:25:11 -0500

--On Monday, November 30, 2020 22:07 -0500 "Theodore Y. Ts'o"
<[email-masked]> wrote:

> On Mon, Nov 30, 2020 at 06:26:00PM -0500, John C Klensin wrote:
>> --On Monday, November 30, 2020 23:38 +0100 Carsten Bormann
>> <[email-masked]> wrote:
>> 
>> > I believe a hard-earned piece of experience I took from
>> > using FTP is that you don't want to do conversions during
>> > transit.
>> 
>> I think we had figured that out by early in 1971. At least in
>> general, I think it is still true.
> 
> And yet, just recently on this mailing list, some of the people
> arguing for the inherent superiority of the ftp protocol as
> compared to http is that with ftp, it *Would* do conversions
> of text files (e.g., crlf mangling, etc.)

Perhaps one of us didn't understand Carsten's comment.  I agreed
because FTP does not do conversions in transit.  The party
requesting the file specifies the form it wants it in and the
system being asked to supply the file either supplies it in that
form... or doesn't.  No conversion "during transit" as I
understood that.

--On Tuesday, December 1, 2020 07:27 -0800 Larry Masinter
<[email-masked]> wrote:

> At the time FTP was developed, PDP-10s with 9-bit bytes and
> IBM mainframes using EBCDIC were common, disk space was
> limited, and transfer with format conversion was necessary.

As just one example, transfer of "plain text" files, the
community had already concluded that, no matter how text was
represented on a particular host, the right solution was to have
a network-standard form in which it could be transmitted.   That
resulted in each system having to support, at most, conversion
between its format and the standard one because, otherwise, each
host would have an N-squared problem where N was the number of
distinct system architectures on the net.  Inside the various
systems, ASCII was represented in five 7 bit "bytes", with one
bit left over, on the 36 bit word of TENEX; in four 9 bit
"bytes", with two leading zero bits in each on the 36 bit work
of Multics; in the first three and last four bits of 8 bit bytes
of some systems (including ASCII on IBM mainframes); and in the
last seven bits of an 8 bit byte on others... and those are
examples, not an inclusive list.  Similarly, there were machines
that used CR as line-end, those that used LF, those that used
CRLF, those that used either a special delimiting control
character other than either of those, and those that used a
length count at the beginning of every line.  

So, even without the decision to allow TYPE E and the reasons
for it, the choice was either an N-squared problem for a
not-very-small value of N or a standard for strings in
transmission.  See RFCs 20 and 137.

Now, almost certainly there are fewer variations for "plain
text" today.  But, even it it were only "Unicode" (and it isn't:
while a large fraction of them are spam, I still routinely
receive messages identified with charset GB2312, GBK, and
ISO8859-1), there would still be the different encoding forms
and many of the same arguments would apply.

But, again, while I cannot prevent people from doing so, for
questions of whether or not the IETF has standardization work to
do, I don't think it is helpful to discuss why FTP was more or
less useful 45 years ago than it is today or whether or not it
is useful for complex file types.   And I don't think it is
useful to try to convince people who find it useful and who
understand its strengths and limitations that they should stop
using it.  The question I am trying to ask is _only_ whether
those who are using and/or supporting it would find an effort to
provide better error response information and/or provisions for
Unicode in UTF-8 useful and whether they would implement and
deploy those changes.  I don't believe a single on-list response
to those questions has been posted yet.

   john

   john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Dec 2020 00:00:09 -0500

No, don't fix FTP. At this point it has been rendered obsolete by SFTP
which is a subsystem of SSH.

FTPS has lost out to SFTP in the market. There is no advantage to
continuing to support a rival and there is a considerable cost. The
interests of the community would be best served by focusing all development
on SSH/SFTP and declaring Telnet and FTP HISTORIC. Doing that might help
focus attention on the fact SFTP doesn't have an RFC and encourage moves to
complete that work.

[That said, I am a little peeved at the lack of a telnet system on some
platforms as I frequently used it to connect to a raw port and rest out
services.]

On the format conversion issue, the FTP spec has a MUST that actually
requires the default client behavior to be to assume an ascii conversion is
desired.

There being a negligible number of ESCIDC and 9 bit machines on the
Internet in the 1990s. this always irritated me to the point of patching
the client to remove the stupid.

The biggest mistake in the Web protocols was accepting the dictum of being
permissive in what is accepted. Horrors like MIME sniffing might had been
avoided if enough browsers had insisted on literal interpretation of
content type. What I find really appalling is that there are circumstances
in which some browsers have at various times been written with the default
behavior of ignoring correctly labelled content and then signalling an
error when it doesn't render under the incorrectly assumed type.

---

From: Keith Moore <[email-masked]>
Date: Wed, 2 Dec 2020 06:42:49 -0500

On 12/2/20 12:00 AM, Phillip Hallam-Baker wrote:

> The biggest mistake in the Web protocols was accepting the dictum of 
> being permissive in what is accepted. Horrors like MIME sniffing might 
> had been avoided if enough browsers had insisted on literal 
> interpretation of content type.

The fundamental problem there is that the server doesn't have a reliable 
way of knowing the content-type.   The server can't reliably tell it 
using filename suffix.   And since the client is blamed when it displays 
content incorrectly, the pressure is inevitably on the client to fix 
things.    I don't think this could have been avoided by different 
language in the HTTP specification.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 2 Dec 2020 07:02:41 -0500

On 12/2/20 12:00 AM, Phillip Hallam-Baker wrote:

> interests of the community would be best served by focusing all 
> development on SSH/SFTP and declaring Telnet and FTP HISTORIC. Doing 
> that might help focus attention on the fact SFTP doesn't have an RFC 
> and encourage moves to complete that work.

I'm not sure that there is one "the" market.   While I like SFTP and 
personally use it more often that I do FTP, my sense is that each has 
established itself in different communities.   FTP use is still 
widespread.   For instance, broadcast TV equipment uses FTP 3rd party 
transfer capability to transfer large media files from video archives to 
video playout servers for airing.

(Of course part of FTP's acceptance might be due to FTP not requiring 
encryption.    I can't imagine that the broadcast TV industry would 
switch to SFTP because it would be so much slower.)

Keith

---

From: Julian Reschke <[email-masked]>
Date: Wed, 2 Dec 2020 13:24:29 +0100

> way of knowing the content-type.   The server can't reliably tell it

In which case it shouldn't send any. Unfortunately, some servers did in
the past, and clients worked around that.

> ...

Best regards, Julian

---

From: Keith Moore <[email-masked]>
Date: Wed, 2 Dec 2020 08:13:22 -0500

On 12/2/20 7:24 AM, Julian Reschke wrote:

> In which case it shouldn't send any. 

And the client ends up needing MIME sniffing code (and probably using 
it) anyway.

MIME email has the same problem; arguably the web inherited this problem 
from email.

Keith

---

From: Adam Roach <[email-masked]>
Date: Wed, 2 Dec 2020 10:38:05 -0600

On 12/1/20 23:00, Phillip Hallam-Baker wrote:
> [That said, I am a little peeved at the lack of a telnet system on 
> some platforms as I frequently used it to connect to a raw port and 
> rest out services.]

If it helps: I've yet to find a system that lacks both telnet and nc 
(netcat) out of the box.

/a

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 2 Dec 2020 18:17:31 +0100

On 2020-12-02, at 17:38, Adam Roach <[email-masked]> wrote:
> 
> If it helps: I've yet to find a system that lacks both telnet and nc (netcat) out of the box.

Indeed, interestingly, for me, nc replaces the existing usages of both telnet and ftp (i.e., unencrypted and third-party transfers).  Except that my brain cannot teach my fingers to stop typing “telnet”, so I usually have that installed in some form (e.g., inetutils) as well.

Grüße, Carsten

PS.: OK, I should probably simply alias “telnet” to “nc -ctv” or some such.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Dec 2020 12:56:48 -0500

> Indeed, interestingly, for me, nc replaces the existing usages of both
    > telnet and ftp (i.e., unencrypted and third-party transfers).  Except
    > that my brain cannot teach my fingers to stop typing “telnet”, so I
    > usually have that installed in some form (e.g., inetutils) as well.

neither nc or telnet is installed on Ubuntu or Windows or openwrt by default now.
I don't think it's installed by default on RASPbian either.
(Hard for me to double check, as naturally, I wind up installing both immediately)

Like Carsten, I have difficulty not using telnet when I should be using nc.
(But, I don't find I should have -t on by default, which is why nc rather
than telnet.  Ah, I remember back writing that proxy-telnet...)

I have on numerous times found that I can't update systems because the update
server insists that I use https, and that I use TLS 1.2 or better, but the
system in question is too old, and it's exactly the TLS 1.2 code that I'm
trying to get.

Should systems be updated more often? Sure, but try telling that to a VM
which has been suspended for a year.  Or any kind of embedded system which
should never be upgraded while in operation.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 2 Dec 2020 18:59:53 +0100

> system in question is too old, and it's exactly the TLS 1.2 code that I'm

(You are not alone.  But that’s the other discussion over at last-call about draft-ietf-tls-oldversions-deprecate, which I so far have managed to not join.)

Grüße, Carsten

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Dec 2020 13:32:46 -0500

> than telnet.  Ah, I remember back writing that proxy-telnet...)

I used to find this an issue and then I started to hit problems because
modern servers increasingly have timeouts on commands to prevent port
exhaustion DoS attacks. So I stopped debugging by hand and wrote a bunch of
different code...

But even if every developer needs to use telnet for debugging on a daily
basis, that is still no reason for telnet to keep its standards status. I
would like to see us being more aggressive in rendering old protocols
obsolete so as to encourage new ones. and to discourage continued use of
insecure protocols.

Take the main remaining use of FTP for example - syncing to cameras over
ethernet. Sure, thats one way to do it. But its insecure which is something
of a problem when the professionals using it are often reporters or
forensics practitioners.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 2 Dec 2020 11:12:26 -0800

> If it helps: I've yet to find a system that lacks both telnet and nc 
I don't think MacOS has telnet out of the box. I vaguely remember having 
to go through quite a few hoops to get it. But I am a pretty clueless 
Mac user, so it was probably mostly my fault.

Mike

---

From: "Scott O. Bradner" <[email-masked]>
Date: Wed, 2 Dec 2020 14:47:01 -0500

brew install telnet

Scott

> On Dec 2, 2020, at 2:12 PM, Michael Thomas <[email-masked]> wrote:
> 
> 
> 
>>> [That said, I am a little peeved at the lack of a telnet system on some platforms as I frequently used it to connect to a raw port and rest out services.]
> I don't think MacOS has telnet out of the box. I vaguely remember having to go through quite a few hoops to get it. But I am a pretty clueless Mac user, so it was probably mostly my fault.
> 
> Mike
>

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Dec 2020 15:57:05 -0500

--On Wednesday, December 2, 2020 13:32 -0500 Phillip
Hallam-Baker <[email-masked]> wrote:

>...
> But even if every developer needs to use telnet for debugging
> on a daily basis, that is still no reason for telnet to keep
> its standards status. I would like to see us being more
> aggressive in rendering old protocols obsolete so as to
> encourage new ones. and to discourage continued use of
> insecure protocols.
>...

Unless the rules changed when I wasn't looking (Scott should
check me on this), the goal of IETF standards is to define
conditions for interoperability 
among those who choose to use them.  Whether incorporated into
the same document or separate, "you should use this in
preference to anything else" or "everyone who wants to part of
the Internet should support this" statements are matters for
Applicability Statements and recommendation levels, not
standards status.  We should not lose sight of the importance of
that distinction, especially because we have had recent working
groups developing protocols for standardization that are of use
to only a tiny fraction of the Internet's users.

Historically (sic) we have moved standards track protocols,
especially Internet Standards, to Historic only when no one is
using them and expecting implementations to interoperate (see
RFC 4450 for a partial explanation), with, e.g., the ARPANET
Host-IMP protocol as a rather good example.  We have sometimes
moved specifications whose use was already formally deprecated
(even if there was not a spec that said "Not Recommended" as
2026 anticipated) to Historic for extra emphasis.  Moving a
document to Historic without doing anything else is nothing more
than a statement by the IETF that the specification is of no
further use as a specification.  2026 says "superseded by a more
recent specification or is for any other reason considered to be
obsolete" but that is the _specification_ not the protocol or
its usability.   As long as efforts to discontinue FTP support
in a particular context or mere questions about adding a
response code or features that might improve contemporary
applicability call forth as much impassioned debate as we have
seen recently, whatever that spec is, it is not Historic.

Keep in mind that the IETF's Standards are voluntary and that,
just as we cannot make anyone implement or use a Standard as we
intend and prefer, we cannot prevent someone from using one of
our specifications just because we have attached a term of shame
to it.  If we don't want someone to use a spec, we need to
explain why in a way that is persuasive to them.

So, if I understand correctly what you are actually trying to
do, by all means write a spec explaining why no right-minded
person would used FTP and/or Telnet and updating RFC 1123 and
765 and/or 854 to explicitly identify them as "Not Recommended".
Moving it (and Telnet) to Historic without making that effort
and while they are still in active use in parts of the Internet
and for some purposes would only serve the purpose of further
damaging the IETF's credibility.  And, if your recommended
replacements are not, themselves, IETF Standards, then, IMO, the
damage to credibility would be even greater.

I will save my opinion for what should be done with such a
spec/proposal if it is written and posted for that event.

best,
   john

---

From: "Scott O. Bradner" <[email-masked]>
Date: Wed, 2 Dec 2020 18:19:41 -0500

I fully agree with John 

I see no justification to move telnet &/or FTP to historic since they are in use (even if
some people would rather that not be the case) and neither presents a clear danger
to the proper functioning of the Internet

Scott

> On Dec 2, 2020, at 3:57 PM, John C Klensin <[email-masked]> wrote:
> 
> 
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Dec 2020 23:28:42 +0000

Hiya,

> to the proper functioning of the Internet

I gotta wonder about that last. Wouldn't it be credible to
argue that telnet is in fact a real danger, if one looks at
all the CVEs that've reported on ports with admin/admin
access? I'm not sure if it'd be the right thing to do, but
I do think one can credibly argue that deprecating telnet
might be worthwhile.

Cheers,
S.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 3 Dec 2020 10:54:33 +1100

> On 3 Dec 2020, at 10:28, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

Default passwords with admin/admin is an orthogonal issue.  It can happen just as
easily with SSH or HTTPS as with TELNET.  Telnet has risks but don’t blame TELNET
for bad password selection.

> <OpenPGP_0x5AB2FAF17B172BEA.asc>

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 Dec 2020 00:22:54 +0000

On 02/12/2020 23:54, Mark Andrews wrote:
> easily with SSH or HTTPS as with TELNET.  Telnet has risks but donâ€™t blame TELNET

Well, yes and no. With telnet that credential is leaked
to everyone listening on the network and with ssh, mostly
there's sshd_config that can be used to repair a dodgy
initial deployment.

S.

---

From: Scott Bradner <[email-masked]>
Date: Wed, 2 Dec 2020 19:32:33 -0500

any prediction son what % of future IoT implementations would drop telnet if the IETF moves the spec to historic?

Scott

> On Dec 2, 2020, at 6:28 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Dec 2020 19:41:36 -0500

> there's sshd_config that can be used to repair a dodgy

Replacing telnet with ssh and still using passwords that never get changed is
less secure in my opinion.   You mention "sshd_config", but frankly, if you
knew how to do that, then you wouldn't have the problem in the first place.

At least nobody pretends telnet is secure.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Dec 2020 19:44:16 -0500

Scott Bradner <[email-masked]> wrote:
    > any predictions on what % of future IoT implementations would drop
    > telnet if the IETF moves the spec to historic?

0%

1) few have telnet on on purpose, so they don't know to remove it.
2) of those who have telnetd on purpose, they never read an IETF spec.
   (Might not even be allowed to read RFCs in their country)
3) of the remaining that intentionally have it, they have it because they
   think that either they don't need security, and/or because they think
   they can't afford the code space.

security is a process that starts with hiring clueful people.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 Dec 2020 00:46:03 +0000

Hiya,

On 03/12/2020 00:32, Scott Bradner wrote:
> any prediction son what % of future IoT implementations would drop 

That's a fair point. (And why I said it'd be credible but
didn't say I'd help with the I-D:-)

On 03/12/2020 00:41, Michael Richardson wrote:
> Replacing telnet with ssh and still using passwords that never get
> changed is less secure in my opinion.   You mention "sshd_config",
> but frankly, if you knew how to do that, then you wouldn't have the
> problem in the first place.

I don't agree. If we assume the system developer is careless,
then it's easier to recover from such a careless developer
if they misused ssh than if they misused telnet I'd say.

S.

---

From: Jared Mauch <[email-masked]>
Date: Wed, 2 Dec 2020 20:04:12 -0500

Since when were IETF people operators that used debugging tools?

I end up using telnet daily to connect to route servers to debug what is going on. I don't care who is watching me as maybe they can fix the problem for me I am debugging. 

This thread is some comedy gold though.

Sent from my iCar

> On Dec 2, 2020, at 7:47 PM, Stephen Farrell <[email-masked]> wrote:
>

---

From: Mark Andrews <[email-masked]>
Date: Thu, 3 Dec 2020 12:52:58 +1100

> On 3 Dec 2020, at 11:22, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 

And there are mechanism like one time passwords where that is mitigated.  You can
also use telnet without passwords.  Whether to use telnet or ssh is about risk
management.  Its also about what is provided.  There are things you will do on
a home network that you wouldn’t do across the Internet.  Choosing to use telnet
should be one of them.

One of the biggest reasons for using telnet was that clients where ubiquitous.
Ssh only came natively to Windows recently (2018 available by default).

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Dec 2020 22:15:43 -0500

On Wed, Dec 2, 2020 at 3:57 PM John C Klensin <[email-masked]> wrote:

> among those who choose to use them.

https://www.ietf.org/about/

"The mission of the IETF is to make the Internet work better by producing
high quality, relevant technical documents that influence the way people
design, use, and manage the Internet."

Seems that the 'rules' have changed. As they should because we are no
longer serving an insular community of a few thousand academics. We have
been operating at planetary scale for decades now.

As for whether IoT device makers would stop using telnet if it was
deprecated, that is a good question. It is not one that I think we should
simply assume we know the answer to. The IETF would like people to move
from IPv4 to IPv6.

This is not the first time I have suggested the following strategy, but
everyone else seems to keep repeating themselves: If the IETF wants to
persuade people to stop using IPv4 and switch to IPv6 it needs to get into
the business of telling people what to use and what not to use.

Oh and as Stephen points out, we have been telling people not to use
insecure stuff for quite a while. We deprecate stuff in the security area
all the time even if people are still wanting to use it. There are people
would be happily using SSL/3.0 today if we hadn't made that really hard.

Oh and yes, I totally reject any set of rules I don't get a vote in
deciding.

---

From: "John Levine" <[email-masked]>
Date: 2 Dec 2020 22:17:38 -0500

>I end up using telnet daily to connect to route servers to debug what is going on. I don't care who is watching me as maybe they can fix the problem for me I am

My guess is that you're using a telnet program but you're probably not using the telnet protocol.

Telnet has a gazillion options to control a Network Virtual Terminal,
since back in the day there was a whole lot more variation among
terminal character sets and control features.

Are you using any of those, or would a program like nc that just sets
up a two way TCP session to a remote server work just as well?

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Dec 2020 22:23:03 -0500

--On Wednesday, December 2, 2020 23:28 +0000 Stephen Farrell
<[email-masked]> wrote:

>> I see no justification to move telnet &/or FTP to historic
>> since they are in use (even if some people would rather that
>> not be the case) and neither presents a clear danger to the
>> proper functioning of the Internet
> 

Stephen,

First, at least from my point of view, if you (or anyone else)
want to make that argument, go for it.  Write the document
outlining the pros and cons, point out the risks and damage you
have seen, and then let's see if it is still possible to have a
mature and intelligent discussion in the IETF about tradeoffs
rather than arguments and discussion about these things that
seem more to do with passions and biases than reality on the
Internet.  

Two suggestions to think about as you (or others) are
contemplating that:

(1) Reread Section 3.3 of RFC 2026.  While I'm not convinced
either would be desirable, it seems to me that reclassifying
telnet (or FTP) as "Limited Use" by describing the risks and
identifying the characteristics of circumstances under which use
might be desirable anyway would be far more plausible that
trying to make it "not recommended".    That might be true of
whatever else is a candidate for someone's "I have a way to do
that on the web and therefore the original protocol is
hopelessly outdated" list [1] as well as some things we have
done/specified already.   

For example, I have worked with several enterprises who think
that they need to have the ability to inspect email traffic
going in or, especially, out.  Some even write employment
contracts in which employees are required to explicitly agree to
that or not work there.    Many of them also believe in the
quality of their firewalls, VPNs, and SSH-based tunnels.  So, to
them, RFC 8314 is unnecessary, a demand for additional overhead,
and, to quote one of the relevant people "just plain arrogant".

And that brings me to...

(2)  People use IETF standards, voluntarily, because they are
the only game in town (or think we are - often for something
new), because they believe the IETF gives good advice, or both.
When we say "do X" to someone who is doing something else or
"don't do Y anymore" to someone who is doing Y, knows it, and
thinks they have perfectly good reasons (or who doesn't know
they are dependent on it until we tell them, the odds of our
being ignored are rather high.  (Scott's question about telnet
and IoT and Jared's application fit in nicely here.)   Perhaps
more important, we invite that person or organization to say,
the next time a proposal to do someone according to IETF
standards or advice comes up, "They didn't consider our
situation, got the previous advice wrong, and were arrogant
about it.  Why on earth should we trust them with this issue."
If we say "to accomplish this task, don't use our Standard, use
this think we haven't bothered to standardize and for which
there are only a couple of implementations instead", the effects
might be even worse.  I've already heard rumblings like that and
assume I'm not the only one.

So, again, if someone wants to write a carefully thought-out
document explaining why, under circumstances you can describe,
there are better alternatives than telnet, FTP, finger, whois,
SMTP, etc.; why they are better; and so on, that might be very
helpful.  It would be especially so if avoided making claims
that those are all possible circumstances.   But the only good
justification for deprecating telnet or FTP -- or even making a
public claim that no one, at least no one in their right minds,
is using them any more -- may involve having a death wish for
the IETF.

   john

[1] I know you don't feel that way and apologize if I've
misstated that, but many of the recent discussions (more in
other threads than this one) have felt more like a culture war
than like reasoned technical arguments.

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Wed, 2 Dec 2020 23:06:15 -0500

> I do think one can credibly argue that deprecating telnet

I'm not convinced by that argument.  How many of these ports are
actually running the telnet protocol?

I may do something like:

% telnet imap.thunk.org 25

However, I'm not actually using the telnet *protocol*.  I'm just using
the telnet *program* to talk to a an SMTP server.  Deprecating the RFC
for the telnet protocol isn't going to magically make all instances of
the telnet program go away, and even if it didn't, netcat (nc) would
still exist.

						- Ted

---

From: Christian Huitema <[email-masked]>
Date: Wed, 2 Dec 2020 22:42:19 -0800

> a home network that you wouldn’t do across the Internet.  Choosing to use telnet

Mark, you had me until "home network". Because most home networks are in 
fact *not* more secure than the open Internet. The illusion of using a 
'secure' network and thus allow unsafe practices is one of big sources 
of attacks!

-- Christian Huitema

---

From: Joe Touch <[email-masked]>
Date: Wed, 2 Dec 2020 23:22:08 -0800

> On Dec 2, 2020, at 10:47 PM, Christian Huitema <[email-masked]> wrote:
> 
> Mark, you had me until "home network". Because most home networks are in fact *not* more secure than the open Internet

Not that I like NATs, but they do afford protection beyond being on the open Internet simply by lacking incoming port mapping.

Joe

---

From: Christian Huitema <[email-masked]>
Date: Wed, 2 Dec 2020 23:44:49 -0800

> Not that I like NATs, but they do afford protection beyond being on the open Internet simply by lacking incoming port mapping.

That's the firewall illusion. It is shattered if someone inside the wall 
falls for a phishing attack, or clicks on the wrong attachment, or 
downloads the wrong program. At which point all these unsafe programs 
that are used "only behind the firewall" become nice avenues for quickly 
spreading the attack much farther than the initial failure. See numerous 
examples of ransomware attacks against small businesses, schools, etc.

-- Christian Huitema

---

From: Christian de Larrinaga <[email-masked]>
Date: Thu, 03 Dec 2020 11:13:32 +0000

there are times when having telnet to test a mail server / email address is helpful?

Happy to have a better sweetie if you can suggest one

C

-- 
Christian de Larrinaga 
https://firsthand.net

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 3 Dec 2020 20:27:43 +0900

Phillip Hallam-Baker wrote:

> declaring Telnet and FTP HISTORIC.

Only to celebrate the stupid proposal of the stupid tool team
(not offending any individual of the team) to make ftp service
of IETF obsolete and the similarly stupid decision of Mozilla?

Though, on 2020/11/07 1:25 in this list,you wrote:

 > Mohta-san,
 >
 > With all due respect for the fact English is not your first
 > language. I read what you wrote but was unable to parse it.

I'm afraid it's your problem that you can't parse our
discussion.

Is English your first language?

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 3 Dec 2020 20:38:48 +0900

> there are times when having telnet to test a mail server / email

Yup. In that sense, all the ASCII based protocols are
telnet servers.

Actually, when I teach ASCII based protocols (ftp, http, etc.)
to students, I let them use telnet clients to access servers
manually.

					Masataka Ohta

---

From: Dave Cridland <[email-masked]>
Date: Thu, 3 Dec 2020 11:47:31 +0000

> Yup. In that sense, all the ASCII based protocols are
This isn't true, in point of fact. FTP's control connection *is* based on
TELNET, but SMTP, HTTP, and others are not.

> to students, I let them use telnet clients to access servers

A conformant TELNET client implementation can (and maybe even will) send
IAC commands over the link, which will confuse HTTP and SMTP, and quite
possibly mildly surprise non-conformant FTP.

I'd suggest you use `nc` instead of `telnet` to avoid this risk.

Dave.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 3 Dec 2020 12:09:40 +0000

> Happy to have a better sweetie if you can suggest one

netcat is probably better for this because it opens up a raw socket and 
doesn't attempt to cook the transport layer, like telnet.

Telnet as an interactive remote login protocol is operationally 
obsolete.  There are better alternatives and few credible reasons for 
new equipment / services to support it.  There isn't an issue for 
existing service stacks to continue to support it on a discretionary 
basis if they want.

In any event, reclassifying a protocol as historic doesn't mean that the 
tools will disappear.  It just means that as a protocol is at an 
evolutionary dead end.

It's ok to admit this sort of thing and not see it as a bad thing. The 
world moves on.

The same applies to finger except more so.  And identd (rfc1413), 
chargen (rfc864), echo/udp (rfc862) and, honestly, cartloads of the 
earlier rfcs.  If there were a gigantic bonfire of a bunch of these, I 
would be happy to supply the marshmallows.

Nick

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 3 Dec 2020 21:15:41 +0900

> TELNET, but SMTP, HTTP, and others are not.

All of them are based on telnet.

Though some of them, including some telnet implementations, may be
extended to support non-ASCII characters, it merely means that
they are extended-telnet servers for extended-telnet clients,
which means there is no reason to obsolete telnet.

					Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 3 Dec 2020 21:21:33 +0900

Nick Hilliard wrote:

> tools will disappear.

It will authorize or even encourage browser developers to deprecate
tools for telnet: URLs, which is a problem.

							Masataka Ohta

---

From: IETF Sergeant at Arms <[email-masked]>
Date: Thu, 3 Dec 2020 17:54:41 +0530

Hi all,

We wanted to let the list know that the sergeant-at-arms (SAA) team 
(described in more detail at [1]) has been in touch with Masataka Ohta 
off-list concerning their recent messages [2][3]. We encourage everyone 
to review the IETF discussion list charter [4] and avoid postings that 
include unprofessional commentary [5].

Thanks,
Dhruv Dhody on behalf of the SAA team

[1] https://www.ietf.org/how/lists/discussion/
[2] https://mailarchive.ietf.org/arch/msg/ietf/hqC2ZtCcA5k4jEWkfTg6jTGwuHE/
[3] https://mailarchive.ietf.org/arch/msg/ietf/FjeFl6vxcVBSUuk3SqkBG8EIhDs/
[4] https://tools.ietf.org/html/rfc3005
[5] https://github.com/ietf/saa/blob/master/unprofessional-commentary.md

---

From: Christian de Larrinaga <[email-masked]>
Date: Thu, 03 Dec 2020 12:27:16 +0000

Nick Hilliard writes:

> Christian de Larrinaga wrote on 03/12/2020 11:13

Yes John Levine mentioned nc earlier. I do use it for some usecases but I find
muscle memory takes over and telnet has a loooong history.  

I have been slowly reviewing and installing newer tools on my linux
laptops over the year. But gaining a 10,000 metre view of the current options takes
time.

> tools will disappear.  It just means that as a protocol is at an 

When one stops eating one's own dog food ....

> would be happy to supply the marshmallows.

sounds like a job to build the wiki for this. 

C
-- 
Christian de Larrinaga

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Dec 2020 07:27:06 -0500

> there are times when having telnet to test a mail server / email address is helpful?

That's a telnet *client*, and it's a program, not a service.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 3 Dec 2020 21:39:33 +0900

> include unprofessional commentary [5].

Without clarifying what part of my message is considered
"unprofessional", only to chill others?

And, I was told that:

: We are reaching out to you because of your recent message to
: [email-masked] [2]. The message contained the following
: language:

: Only to celebrate the stupid proposal of the stupid tool
: team (not offending any individual of the team) to make
: ftp service of IETF obsolete and the similarly stupid
: decision of Mozilla?

: which the SAA team considers unprofessional commentary [3]
: for insulting and demeaning the team.

even though I have already explicitly confirmed that it is
OK to recognize collective stupidity of IPng/IPv6 and LISP
teams?

It was and still should be OK to call IPv6 and LISP garbage.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 3 Dec 2020 21:43:19 +0900

> That's a telnet *client*, and it's a program, not a service.

Declaring a protocol historic means to discourage supporting
implementations of the protocol.

						Masataka Ohta

---

From: Joe Touch <[email-masked]>
Date: Thu, 3 Dec 2020 07:11:41 -0800

N

> On Dec 2, 2020, at 11:50 PM, Christian Huitema <[email-masked]> wrote:
> 
> 
> That's the firewall illusion. It is shattered if someone inside the wall falls for a phishing attack, or clicks on the wrong attachment, or downloads the wrong program. At which point all these unsafe programs that are used "only behind the firewall" become nice avenues for quickly spreading the attack much farther than the initial failure. See numerous examples of ransomware attacks against small businesses, schools, etc.
> 
> -- Christian Huitema

Sure, but you have to attack the machines behind a firewall some other way *first*. 

I didn’t say they were safe, just safe*er*.

Joe

---

From: Keith Moore <[email-masked]>
Date: Thu, 3 Dec 2020 12:25:34 -0500

On 12/3/20 6:47 AM, Dave Cridland wrote:

>
> A conformant TELNET client implementation can (and maybe even will) 
> send IAC commands over the link, which will confuse HTTP and SMTP, and 
> quite possibly mildly surprise non-conformant FTP.
>

nc works of course, but every telnet client I know of disables option 
negotiation if you specify a port number other than 23.

Keith

---

From: Adam Roach <[email-masked]>
Date: Thu, 3 Dec 2020 11:43:00 -0600

On 12/2/20 13:12, Michael Thomas wrote:
> I don't think MacOS has telnet out of the box. I vaguely remember 
> having to go through quite a few hoops to get it. But I am a pretty 
> clueless Mac user, so it was probably mostly my fault.
>

Yep, macOS doesn't come with telnet. But it seems to always have nc 
installed at /usr/bin/nc -- and the man page certainly gives the 
impression that the systems ship that way, since there are a bunch of 
interesting new options prefixed with "--apple-"

/a

---

From: Christian Huitema <[email-masked]>
Date: Thu, 3 Dec 2020 10:54:11 -0800

> I didn’t say they were safe, just safe*er*.

I understand why you say that. Machines behind a NAT or a stateful 
firewall cannot be remotely probed for low level vulnerabilities, so you 
do get some reduction of the attack surface. My contention is that this 
reduction is far from being sufficient, because attackers have found 
many ways to project themselves through NATs or firewalls. If you allow 
for unsafe practices because the machines are behind a NAT or a 
firewall, these unsafe practices will result in catastrophic cascades of 
failures after a single breach happens.

-- Christian Huitema

---

From: Keith Moore <[email-masked]>
Date: Thu, 3 Dec 2020 15:05:22 -0500

On 12/3/20 1:54 PM, Christian Huitema wrote:

> firewall cannot be remotely probed for low level vulnerabilities, so 
> you do get some reduction of the attack surface. My contention is that 
> this reduction is far from being sufficient, because attackers have 
> found many ways to project themselves through NATs or firewalls. If 
> you allow for unsafe practices because the machines are behind a NAT 
> or a firewall, these unsafe practices will result in catastrophic 
> cascades of failures after a single breach happens. 

+1

For that matter not even "air gapped" networks are really safe. There's 
almost always some laptop or other that occasionally connects to such 
networks, and malware can creep in that way.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 3 Dec 2020 15:45:41 -0500

> networks, and malware can creep in that way.

There are viable controls but they are very expensive. At VeriSign we
constructed a tier 6 SOC and kept the machines that perform offline
operations in a very pricey safe along with the HSMs (see the CPS which
documents all of that).

Firewalls are an effective means of mitigating risk. They do not eliminate
risk. They don't come close.

Perimeter security is useful but incomplete. A starting point for any
security analysis has to be 'what stuff do I have control over and what
stuff do I have no control over'. But perimeter security has been declining
in effectiveness for decades now. It is the 1980s level car alarm that
every thief has learned how to disable.

To go further, we have to start looking a security policy and we have to
look at separation of roles. And right now the research community focused
on that approach is tiny. We are starting to get some traction with
threshold cryptography which is the only technology that provides a real
hope of protecting data at rest whether in the cloud or elsewhere.

Suggest doing security policy and people start bleating that it is hard.
Well if it was easy we would be doing it already.

---

From: Keith Moore <[email-masked]>
Date: Thu, 3 Dec 2020 16:02:56 -0500

On 12/3/20 3:45 PM, Phillip Hallam-Baker wrote:

> operations in a very pricey safe along with the HSMs (see the CPS 
> which documents all of that).

Yes but this is a far cry from the typical "air gapped" LAN which is an 
Ethernet switch or WiFi access point that just doesn't happen to have an 
upstream link (most of the time).

And for most sites the kinds of measures you employed at VeriSign (glad 
you did!), or really anything more than perhaps an extra lock on the 
gate or door, would be prohibitively expensive.

I know of sites that are part of critical infrastructure, on concrete 
pads in the middle of nowhere, surrounded by a chain link fence (if 
that).   The fence is just to keep the nearby cows out.

Keith