Re: Call for Community Feedback: Retiring IETF FTP Service

Keith Moore <> Mon, 16 November 2020 14:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 516773A10CB for <>; Mon, 16 Nov 2020 06:33:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BkzWCWGA5Y-a for <>; Mon, 16 Nov 2020 06:33:38 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A5283A122A for <>; Mon, 16 Nov 2020 06:33:16 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 554025C01D0 for <>; Mon, 16 Nov 2020 09:33:16 -0500 (EST)
Received: from mailfrontend2 ([]) by compute3.internal (MEProxy); Mon, 16 Nov 2020 09:33:16 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=krbprpUCgjarmY5XHskvZqCIxJ4x4N0h/72bbREnA xU=; b=ht0cXOL2zV4rvlGDHq4eTX/aBLKGfOwkIdmdMtXn5czmJu3aWd/26siPc L7/Aahk+zOKAAIqPmh+DmjCN1UnHD30OvX986+j9aDxxl29RWKQ1PcuLmAkCEWj0 wrdLpRjBmwp4fXrnWSbZAfM4BFJLONiLZogz5Ud4BG8pE/fq/R8HpnQavnfVFK9j 0Y1NWUkWdQiNoo8z5p3UAHIRleye8gH3rj2/Ch9asf2P/pvKCqux77MYxIagLAgd WlrhdkAbRTzKlNNHwY5Fdujm/Q9OGdFvciW4KjZtXM3snOrGu54SspfGyMYN/+dB 1dOd9wxuZl0VnAubK0swvqcmyGRIQ==
X-ME-Sender: <xms:q42yX-2IO1wy5gkQCv_rF66SEh5gsy7Gn1-ipHtZEBVq5QLzMD990Q> <xme:q42yXxFX0MonHhYmdPnDao4vvQJnGCBqmWgSvrpmEr7ng1Fl05xK7tg-KVJcVzgwF dWT0TtH6kvftg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefuddgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeehleehtdeggf duuefgvdejhfefleeuteetuedtveffieefleeuteeiheetudeuudenucffohhmrghinhep ihgvthhfrdhorhhgpdhhthhtphgsrggtkhhinhhgshhtohhrvghonhhthhgvshgrmhgvfh hilhgvshihshhtvghmshdrrghsnecukfhppedutdekrddvvddurddukedtrdduheenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmohhorhgvse hnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh
X-ME-Proxy: <xmx:q42yX26w-oERnOacXEwh2kU6Ki8nXKwZOUZ8icjasaD6n5ZjPEORzQ> <xmx:q42yX_1ei-CDBiJfXokSCBSrhkDtSqMYjbC5YlvoBN0fG1sF8RrocA> <xmx:q42yXxGELgbn1a0gNuxshLlwdR4izZ74dmElZloNQERWKi6SJG63zg> <xmx:rI2yX5HcKZvK1JAKKBQir874ssQuBfPZUReDgSREQHYIW9ywZc2GDA>
Received: from [] ( []) by (Postfix) with ESMTPA id 6B1EB3064AB5 for <>; Mon, 16 Nov 2020 09:33:15 -0500 (EST)
Subject: Re: Call for Community Feedback: Retiring IETF FTP Service
References: <> <>
From: Keith Moore <>
Message-ID: <>
Date: Mon, 16 Nov 2020 09:33:12 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Nov 2020 14:33:40 -0000

On 11/16/20 5:43 AM, Russ Housley wrote:

> I support turning off the FTP service at The FTP daemon places frustrating constraints on the file system structure.  HTTPS offers much greater security, and it does not impose constraints on the file system structure.

Perhaps you could elaborate on this a bit?   It seems to me that it's 
not the FTP daemon that's placing the constraints on the file system 
structure,  but rather, the expectation that RFCs will be available at 
well-known URLs derived from the RFC number, and I-Ds will be available 
at well-known URLs derived from the I-D identifier.   Sure, a typical 
HTTP server does allow more flexibility at mapping URLs to filenames 
than a typical FTP server does, but only at the cost of a certain amount 
of operational hassle - those mappings have to be maintained.

In practice it also seems that HTTP encourages the destabilizing of such 
interfaces over time, as there's a desire to conform to the latest 
fashion in user interfaces, creating pressure to rearrange the file 
system to suit current whims.

At any rate, there's no requirement to maintain the FTP backing store 
and the HTTP backing store on the same file systems.   As John Levine 
helpfully pointed out, the amount of storage required is fairly small.   
And I understand that there's also a commitment to maintain the file 
structure and make it available using rsync, so I don't think 
deprecating the FTP service is helpful in this regard.

As for the security issue, it seems like any risk resulting from 
exposure of FTP channels to eavesdroppers is entirely on the client, and 
clients are able to choose for themselves whether this is a significant 
enough risk to migrate to a more secure, but less stable, programming