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