Re: Telnet and FTP to Historic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 02/12/2020 23:54, Mark Andrews wrote:


On 3 Dec 2020, at 10:28, Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote:


Hiya,

On 02/12/2020 23:19, Scott O. Bradner wrote:
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

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.

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.

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.


Cheers,
S.

Scott
On Dec 2, 2020, at 3:57 PM, John C Klensin <john-ietf@xxxxxxx> wrote:



--On Wednesday, December 2, 2020 13:32 -0500 Phillip
Hallam-Baker <phill@xxxxxxxxxxxxxxx> 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


<OpenPGP_0x5AB2FAF17B172BEA.asc>

Attachment: OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux