Hiya, On 06/04/15 19:41, Ned Freed wrote: > > >> 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? > > It's interesting precisely because it's one of the services we use to provide > access to our content and it's one that is intrisicly hostile to privacy. > > Even more interesting is how its presence cuts both ways: As long as we have FTP > access, we cannot claim to have secure-only access (which makes some people > happy and others unhappy). But at the same time this can be used as an argument > justifying tightening up or even eliminating non-secure access via other > protocols. So I'm with Sam on this one, having read and thought a bit about the above, I just don't think this is an interesting case. > >> In my head, how to appropriately setup privacy friendly defaults for >> http is much more interesting (and by "appropriate" I do include maybe >> keeping some form of cleartext access, perhaps no longer as default, >> but that'd have to be figured out). > > Having spent not-inconsiderable time on implementing scripts for performing > automatic operations on various web site content, my assessment is that this > general area is a complete mess that includes conspicuous shortcomings in > protocols, best practice recommendations, implementations, libraries, > distributions, and deployments. As a bonus, it even drags in certificate > validation, revokation, and expiration issues. > > Of course this doesn't mean that the IETF has to deal with the entire mess as > part of its web site policies. But just to provide an example of how deep even > the IETF's part of the rabbit hole goes: I use a stylesheet that sucks in the > RFC index in XML from the RFC Editor via http (not https), and uses it to > correctly present the statuses of various RFCs in our generated documentation. > > Now suppose the RFC Editor were to switch to https-only access. Or suppose we > were to extend this to handle references to Interent Drafts. Whatever. The > issues this very simple application would face include: > > (1) Does the application software even include https support as an option? > (2) Does the packaged version we're using have that support compiled in? If > not, are we able to rebuild it or find an alternative? > (3) Does the change create issues for proxies or proxy configuration? > (4) Are there SSL/TLS compatibility issues? > (5) What happens if the IETF screws up their certificate handling? Can we > turn off cerificate validation? > > And this is a very straightforward case. Things get even messier if you're > writing applications that access web data using libraries in PHP, Perl, Python, > etc. If you think all of this stuff just works seamlessly and effortlessly, you > need get out more. > > I note in passing that I have on a couple of occasions found FTP to actually be > the better alternative to HTTP for this sort of thing. (But admittedly never > when proxies are involved.) And so we come full circle. > > One way to look at all this is that the IETF and friends have for better or > worse create a lot of what people have come to regard as public, stable > identifiers for accessing various resources. We mess with those at our peril. > Perhaps including those that begin with "ftp:". I fully agree that identifier stability is a good thing and one to not break without good reason. On tooling - I do think that has improved a lot over the last 4-5 years, and if you think it hasn't you need to get out more:-) But, yes, "--no-check-certificate" and similar are still far too commonly needed in general, though hopefully not with the IETF or RFC editor sites. (I've not played about, but I've also not noticed an IETF/RFC editor cert expiry glitch for a couple of years, and I used see 'em now and then before.) And I have some hope that the acme work [1] we're likely to charter might help there too, but I'd not blame someone for being more skeptical given our previous failures in terms of making security things work well and easily for admins. So I'd agree that we're not now at a stage where we could credibly ask to turn off cleartext access to all IETF materials even if we all agreed we wanted that. (Which we clearly do not.) However, I do think we ought be trying to migrate towards the defaults being more privacy friendly and I also do think that we can make real progress in that respect. Lastly, there are a few interesting questions to consider if/when we get to the point where we could possibly operate in some kind of ciphertext only mode. It's not the same thing at all, but I like the example of the mozilla download server that has to keep loads of old/crap crypto options [1] so that it can update a FF that still uses the old/crap stuff. That I think is a much more interesting corner-case than FTP access and I bet if/when someone really gets to properly work on the issue of privacy for access to public IETF materials, then they will discover other equally interesting things. S. [1] https://www.ssllabs.com/ssltest/analyze.html?d=download.mozilla.org&s=63.245.217.36 [1] https://www.ietf.org/mailman/listinfo/acme > > Ned >