Re: FTP as an interesting privacy example

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> >>>>> "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.

Do the servers the IETF has deployed at present support it? AFAIK they
do not. And if they don't, it's only relevant if there's a proposal to
move in the direction of using it.

> so, we absolutely could have secure ftp.
> This is even more true if you include sftp.

Why would we? It's a completely different protocol.

> * 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.

I'm skeptical the security properties are the same, but let's assume for the
moment they are. That doesn't mean the operational characteristics are the
same. Is rsync commonly used by individuals as a means of fetching specific
documents? Is rsync commonly used by applications to access web data?

AFAIK the answer to both those questions is "no".

> 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.

Whereas it sounds to me like we're eliminating one cleartext technology and
not replacing it with anything. And that's a significant change to the
landscape.

				Ned





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]