>>>>> "Ned" == ietf <ned> writes:
>> On 06/04/15 18:45, Ned Freed wrote:
>> >> My point is only that if we want to debate the appropriate
>> mechanisms >> to put in place to protect the privacy of access to
>> public IETF >> information, then let's not do that based on the
>> FTP corner case, but >> by considering the general question.
>> >
>> > And I quite simply disagree with this approach. I think FTP
>> provides an > interesting test case and context under which to
>> consider the more > general question.
>> Really? I honestly don't get why FTP is at all "interesting" from
>> the privacy of access POV. Can you explain?
Ned> It's interesting precisely because it's one of the services we
Ned> use to provide access to our content and it's one that is
Ned> intrisicly hostile to privacy.
So, I find this flawed for two reasons:
* ftp has multiple security layers including GSS-API and TLS. I'm
certainly aware of servers and clients that implement this.
so, we absolutely could have secure ftp.
This is even more true if you include sftp.
* Rsync, which we seem to be favoring over ftp has the same security
properties as ftp. That is, while there are secure channels over
which you run rsync, the most common deployments of anonymous rsync
are insecure in exactly the same way as ftp and I suspect have similar
client deployment issues: secure rsync is available but for anonymous
access secure rsync is a bit harder to set up.
Note that authenticated rsync is an entirely different situation; there
security is expected.
So, to me it sounds like we're replacing one cleartext technology with
another.
I am failing to see the pervasive monitoring implications for this
transition.