Re: Telnet and FTP to Historic

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

 




> 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.

> 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>

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@xxxxxxx





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

  Powered by Linux