On 11/17/20 2:20 AM, Adam Roach wrote:
The most important point that I made up-thread is that extra services provide extra attack surface.
Yeah, I get that. I've built lots of IIoT systems that had to rely on a number of services, and it's always been a struggle to get the attack surface down to a minimum. (The struggle is that almost nobody wants to spend the time/money required to do that, because security on a device that lives in a customer's environment is seen as Somebody Else's Problem.)
But, as I'm sure you're aware, moving everything to a single protocol doesn't necessarily address the problem so much as move it. And somehow I don't think the right answer is to force people to use less functional protocols. It would take more time than I've spent already to evaluate WebDAV's suitability to replace FTP. There are lots of questions to consider, such as whether WebDAV supports symlinks, whether there are WebDAV clients out there that are as capable as FTP clients, etc. I've never actually seen anyone use a WebDAV client.
There's also a lot that could go wrong when changing how the service is implemented. Like, I've lost count of the number of patent cases I've participated in, in which it was extremely important that RFC dates were preserved. Both FTP and HTTP support file dates, but it's harder to get at them using a web browser than with an FTP client. Since the dates aren't as visible from HTTP, is someone going to fail to preserve them when copying? I'm reminded of the statement I saw earlier that it's okay to regenerate the text files from the XML. Bad Idea.
Keith
