> On 3 Dec 2020, at 11:22, Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote: > > > > 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. 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). > 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> > <OpenPGP_0x5AB2FAF17B172BEA.asc> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx
