Re: Telnet and FTP to Historic

[Stephen Farrell <[e-mail]>]

On 02/12/2020 23:54, Mark Andrews wrote:
> 
> 
>> On 3 Dec 2020, at 10:28, Stephen Farrell <[e-mail]> 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 <[e-mail]> wrote:
>>>>
>>>>
>>>>
>>>> --On Wednesday, December 2, 2020 13:32 -0500 Phillip
>>>> Hallam-Baker <[e-mail]> 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>
>