Hi, Sam's right. We should do better than simply replacing one insecure service with another. Eliot On 4/6/15 10:27 PM, Sam Hartman wrote: >>>>>> "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. > > >
Attachment:
signature.asc
Description: OpenPGP digital signature