Re: Call for Community Feedback: Retiring IETF FTP Service

Adam Roach <adam@nostrum.com> Tue, 17 November 2020 07:21 UTC

Return-Path: <adam@nostrum.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 159DB3A1129 for <ietf@ietfa.amsl.com>; Mon, 16 Nov 2020 23:21:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.08
X-Spam-Level:
X-Spam-Status: No, score=-2.08 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, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 XUdvn-giE381 for <ietf@ietfa.amsl.com>; Mon, 16 Nov 2020 23:21:02 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 526BF3A1128 for <ietf@ietf.org>; Mon, 16 Nov 2020 23:21:02 -0800 (PST)
Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 0AH7Kx6X057696 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 17 Nov 2020 01:21:00 -0600 (CST) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1605597661; bh=ZYPSrUvr8xViXgh8DiqCCIu8Bz5BrlJSDCN+ntpsCnE=; h=Subject:To:References:From:Date:In-Reply-To; b=Z++BXWWDE6ymDnlzX4ysXFRikSKvJRzXJm88iLrOXPg4FNrxBqnsVLodurmaG/Cgb rdvwzC0kTmO70JZPSi8RPb7U+/PT3sVxpDcQv0BaWmISerkc5DKXoy+WqsqfoIidpb pr0IpNwXzrkSeOM0PfSN0Z80VVrVDm3SWwSyc1qE=
X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48]
Subject: Re: Call for Community Feedback: Retiring IETF FTP Service
To: Keith Moore <moore@network-heretics.com>, ietf@ietf.org
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> <a02e15f2-34fb-4124-7ba0-c0ee0070b39f@network-heretics.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <6a29096e-c76e-9bde-388c-bf411b235346@nostrum.com>
Date: Tue, 17 Nov 2020 01:20:53 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <a02e15f2-34fb-4124-7ba0-c0ee0070b39f@network-heretics.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/y2EXJcnpvAp8dJ9ryYXDgUCOQtI>
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 07:21:04 -0000

On 11/16/2020 11:42 PM, Keith Moore wrote:
> But there really should be a good reason to make such a change.   I 
> have run FTP servers before; they're not much trouble.


I've run SMTP servers quite a bit. They're not much trouble. Except for 
that one time when someone hit me with some kind of Postfix buffer 
overflow exploit that allowed them to append commands to the end of 
/etc/rc.local that downloaded heaven knows what (it appeared to take 
some blunt but effective measures to hide its tracks) and which got 
bootstrapped on reboot. I lost the most part of two days rebuilding the 
server from the ground up and painstakingly restoring data from backups 
as I examined it to ensure it hadn't been corrupted by the attacker. 
(And that was presumably someone just opportunistically scanning port 25 
across the network randomly to look for vulnerable servers -- the risk 
is much higher for high-profile organizations that someone might take a 
beef with.)

The most important point that I made up-thread is that extra services 
provide extra attack surface.

That's the big cost -- and it's more significant an expense than opex by 
a fair amount. To be clear, it's a cost to be considered rather than a 
hard blocker. I mean, I still run an SMTP service on that same server, 
because it has ongoing utility for me that I can't easily replace. But I 
certainly scaled back the number of publicly-visible services I run on 
that machine after that experience. Each one added risk, and the 
amortized cost of that risk across time (as measured in potential person 
hours to recover from an attack) was generally larger than the value of 
the service for most of the services I had previously turned on.

And *that's* the calculus I'm applying in this scenario. Nothing to do 
with what's fashionable, or how I personally think everyone ought to use 
computers, or some notion that stable APIs are irrelevant. Those would 
all be questionable reasons for making a suggestion to retire a service, 
and it's uncharitable to assign such motives to me or anyone else 
without supporting evidence. I'm basing my suggestion here on a 
straight-up cost/value evaluation.

In any case, I've said my bit, and I believe my analysis holds up to the 
scrutiny you've put it through. You and others can make of my input what 
you may, but I'm really out of time to engage in a detailed 
back-and-forth here, so this is probably the last message I'll be 
sending on the topic.

/a