Re: Call for Community Feedback: Retiring IETF FTP Service

Daniel Migault <mglt.ietf@gmail.com> Tue, 17 November 2020 05:04 UTC

Return-Path: <mglt.ietf@gmail.com>
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 6E1843A0D9D for <ietf@ietfa.amsl.com>; Mon, 16 Nov 2020 21:04:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 iomItJZwRPKm for <ietf@ietfa.amsl.com>; Mon, 16 Nov 2020 21:04:01 -0800 (PST)
Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE5343A0D99 for <ietf@ietf.org>; Mon, 16 Nov 2020 21:04:00 -0800 (PST)
Received: by mail-vs1-xe2b.google.com with SMTP id m16so10405946vsl.8 for <ietf@ietf.org>; Mon, 16 Nov 2020 21:04:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Tc2gMMQvBW8p2XmEQJbznCxiucroxYBe9BbiG+ODsQU=; b=oTne+4L6MhqywT72gkWHekKjBOFMjDt2ckzWhc5rMzzMgebQKhkZ0wUWU7i81MIWl4 pr8usP4Qeh6ClK6/OIB+iMrwygbE1YSD+nL3EXtT/5wbgnIe1fj06GdiPyaUtYK2OLHI /3vzpGSaDi8/7100azqldeKACUowx2Y4e0mK1tu7tqPqhjU/QHEJ9WWauBsQJABLKqz9 aWBwsB95G0rJReURLQ6uSIE8HuYj5OMh7AZKr42ohh2yqEIE9ln1yloD5t+H7p7TeZ5A ZB/1lfWZTEaG3gw8iwXwgRrxEl+6r1ZrNk3CiVc9DaX2rjvLSIJ09fhOC0ZBpaURvpId 7l8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Tc2gMMQvBW8p2XmEQJbznCxiucroxYBe9BbiG+ODsQU=; b=Yz/aVNT2SF0pcTybRqvzGSf0YfFlTyAEFvBVj9r7sb4Q6odk40xFCdxRgCP5XRCuQo BC3ZgdA52imUozienZwiY9MWRBGK2q+AmeBrkHTwnNF/BeINFn49u3OYm4ubnPD2Xy9G vliyVidMMi4sZe+DL0i4QmcZYCSL6x+WEnty7aGDZXHNAAvlxQRH8PZ3oa8bVGVngmMA ivYo9stoEQa/XtcCR0q1oqFNJ9p47WD4g4EtJv0Lk7TPZlp6wlCYBrzhLt7UwvAvdv3e meaXFU7HSFoMNOF3f2Ke6OdMRoEEzd6S+JsirHETVyMiwFh+y89/e1XZ6JaPSk8kgKIr SP9g==
X-Gm-Message-State: AOAM533qdbyRAyKOmcUIyG+RU2ZK0CNq7AR/aZ+c3cugBTslz7WfZZ/u lTKDQ5GuFJd/g3zbDJx2qS50kuWdnmkYDoZO6UkdIaIyiSM=
X-Google-Smtp-Source: ABdhPJxL/HRwEllo56Rqw0Ad+11VEbXabXEtbOTSBeV7JQzp4OG0ZY5rUqGarNLpTNmwdKzAo8TQWt+aaMvm+FjXehw=
X-Received: by 2002:a67:6981:: with SMTP id e123mr5326606vsc.40.1605589439783; Mon, 16 Nov 2020 21:03:59 -0800 (PST)
MIME-Version: 1.0
References: <af6ab231024c478bbd28bbec0f9c69c9@cert.org> <0D41F3FD-BA1F-4716-A165-4FE7529431A9@vigilsec.com> <D26DCBB6-3997-4A73-BB46-867B4FD79BD2@eggert.org> <27b80ed2-76fb-aee7-f22d-de56019e9aa9@nostrum.com> <a8bdd67a-13ea-4433-aa38-9cfd48ea28da@network-heretics.com> <0e875497-9986-a0d9-8354-3eac26b7f882@nostrum.com>
In-Reply-To: <0e875497-9986-a0d9-8354-3eac26b7f882@nostrum.com>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Tue, 17 Nov 2020 00:03:48 -0500
Message-ID: <CADZyTknX5=68YbmZTxOT6Ye=VeixgPzVM8P7tgjGPyP6WCtCfw@mail.gmail.com>
Subject: Re: Call for Community Feedback: Retiring IETF FTP Service
To: Adam Roach <adam@nostrum.com>
Cc: Keith Moore <moore@network-heretics.com>, IETF Discussion <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000036a90b05b4466c6b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/JOOdTgOySn6j-SSJMQCXtnLmTDU>
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: Tue, 17 Nov 2020 05:04:03 -0000

Putting opex aside, it seems to me that modern communications need to be at
least authenticated so ftp cannot stay as it is. I might be missing
something, but switching ftp to https seems to me quite straight forward
and at least much easier than switching to sftp or ftps. Given the support
of https versus ftp, I also believe reducing the surface of attacks and
relying on probably better maintained code is probably a good switch. I
believe that switching to https is a good move

 Yours,
Daniel

On Mon, Nov 16, 2020 at 5:16 PM Adam Roach <adam@nostrum.com> wrote:

> On 11/16/20 11:12, Keith Moore wrote:
> > On 11/16/20 11:48 AM, Adam Roach wrote:
> >
> >> In the analysis, I think there are two costs to consider and one
> >> benefit. The benefit of leaving it online, of course, is that some
> >> small group of users still find utility in FTP.
> >
> > IMO that misstates the benefit.   A stable service can have a large
> > (and long-term) benefit even if only a few clients at a time use it.
>
>
> Only read in a vacuum. If you read further, I argue for the stable
> interfaces you want. I believe that your objections (here and elsewhere)
> mentioning "user interface" conflate HTTP (transport) with HTML
> (markup), and mixing user interface into the RFCs isn't a foregone
> conclusion: the requirement you have of not mixing display in with
> documents is why I suggest that raw versions be made available. And I
> even argue for making the filesystem mountable like you requested, even
> if I consider that use case to be a bit baroque.
>
> I'm sympathetic to the position that all change can be disruptive, and I
> understand that you know how FTP works and are comfortable with it. At
> the same time, I'm not yet seeing any requirements that you've put forth
> that can't be met pretty trivially with HTTP, other than an inferred
> bedrock requirement of "this must not change at all."
>
> I get it. It's annoying when a technology we like falls by the wayside.
> But I think the costs I describe in my previous message are real, and
> the use cases described so far can be entirely met with HTTP. So I think
> a critical evaluation of the pros and cons points to retiring the
> service. YMMV, of course, but I encourage you to reflect a bit more on
> how much of your reaction is pushback on any change at all versus
> actually losing the ability to do what you want to do.
>
> /a
>
>

-- 
Daniel Migault
Ericsson