On 04/04/2014 12:35, ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com wrote:
My reaction is also to ask "Why?" Security and privacy involve
trade-offs where various costs (including operational difficulty) are
weighed against the benefits, such as protecting information from
unauthorized disclosure or modification. So, I'd suggest that a
blanket statement isn't a good idea, but rather, a service-by-service
decision should be made. For example, XMPP and document submission
may justify requiring encryption while email and document retrieval
might not.
Bingo. There's a perfectly reasonable case to be made for protecting any
sort
of authorization/authentication exchange and not allowing alternatives.
But in the case of document distribution, our primary goal should be to
insure
maximum availability and access to the information we provide, including
to those who are unable to whatever reason to use protected services.
And yes, I'm aware of the argument that access to certain standards,
especially
ones themselves having to do with security, might be problematic to folks
living under some repressive regime or other. I don't buy it, mostly
because that level of paranoia is going to regard any sort of access to
IETF materials whatsoever as a red flag, especially it was conducted over
TLS/SSL.
That may be, but that doesn't mean we shouldn't offer privacy of
access to those who want it.
I never said we shouldn't offer it. The previous discussion was largley
about requiring it.
I think we need to distinguish various
quite separate issues. Off the top of my head, I can see:
* authenticity and integrity of data coming from the IETF site;
Your problem here is people get IETF data from many sources besides the
IETF site. Indeed, alternative data stores may provide access alternatives
for those concerned about being seen accessing IETF data in the obvious way.
As a result I don't see how transport security offers a meaningful solution
here. We should instead be looking at various signature mechanisms.
* privacy of the fact of access, if the user wants it;
Again, there's nothing wrong with offering secure access as an option.
Wikipedia is the obvious example of a site that does this.
* preventing access to the IETF site being used as an attack
vector for either the site itself or the remote user
(which indirectly includes protecting the privacy of
personal information held at either end);
Certain aspects of this are easy, others are hard, and some are probably
research problems.
Ned