Re: Telnet and FTP to Historic

Mark Andrews <marka@isc.org> Wed, 02 December 2020 23:54 UTC

Return-Path: <marka@isc.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1BE13A161C for <ietf@ietfa.amsl.com>; Wed, 2 Dec 2020 15:54:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGu1m8u428sc for <ietf@ietfa.amsl.com>; Wed, 2 Dec 2020 15:54:41 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CEB23A1619 for <ietf@ietf.org>; Wed, 2 Dec 2020 15:54:41 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 116653AB0AA; Wed, 2 Dec 2020 23:54:41 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id EB07716006F; Wed, 2 Dec 2020 23:54:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D9AD7160046; Wed, 2 Dec 2020 23:54:40 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4p_MRZsO1_oo; Wed, 2 Dec 2020 23:54:40 +0000 (UTC)
Received: from [172.30.42.68] (n114-75-149-106.bla4.nsw.optusnet.com.au [114.75.149.106]) by zmx1.isc.org (Postfix) with ESMTPSA id 3AB0E16006F; Wed, 2 Dec 2020 23:54:39 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
Subject: Re: Telnet and FTP to Historic
From: Mark Andrews <marka@isc.org>
In-Reply-To: <08035677-a35e-45ed-39e9-b01df6d01010@cs.tcd.ie>
Date: Thu, 03 Dec 2020 10:54:33 +1100
Cc: "Scott O. Bradner" <sob@sobco.com>, "John C. Klensin" <john-ietf@jck.com>, Michael Richardson <mcr+ietf@sandelman.ca>, Carsten Bormann <cabo@tzi.org>, Phillip Hallam-Baker <phill@hallambaker.com>, IETF Discussion Mailing List <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <AD188A77-24EA-4C63-B9A8-2F901969269D@isc.org>
References: <AA1E0A8464BC45FB4FA44684@PSB> <2D63A357-E253-462C-864D-2BF96D3E2E18@tzi.org> <F4CD3381C5D0E24C91FC4A91@PSB> <20201201030759.GJ5364@mit.edu> <5720F933910C959C9278EBCF@PSB> <CAMm+LwgpcLxSdzgfJy2441hjNWP=Fui-f8Oq1bZB=2QdZeOUNQ@mail.gmail.com> <0c5a4935-f0b6-4b86-dc0e-3b4466bc09a4@nostrum.com> <F1FF9720-AA72-4B92-ABE7-6E0E875059BA@tzi.org> <16446.1606931808@localhost> <CAMm+Lwj51YLpwZLCxsVeg=6tBwaG845Kg4WN4hbA8Bv=pjjKrQ@mail.gmail.com> <C9D1281FC33DACED4FB385A3@PSB> <6B1BC8E3-913D-4683-A463-AD6099103749@sobco.com> <08035677-a35e-45ed-39e9-b01df6d01010@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/akrFMBP56rpDj5i6Ot-vNWgeFOs>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Dec 2020 23:54:43 -0000


> On 3 Dec 2020, at 10:28, Stephen Farrell <stephen.farrell@cs.tcd.ie> 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@jck.com> wrote:
>>> 
>>> 
>>> 
>>> --On Wednesday, December 2, 2020 13:32 -0500 Phillip
>>> Hallam-Baker <phill@hallambaker.com> 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@isc.org