Dean,
Here are responses to your comments:
Too bad. We can try to minimize the impact, but a net that gets you killed
because
the wrong person heard you say the wrong thing is worse than one with slightly
less bandwidth or temporal QoS.”
I'm not sure I understand the context of your assertion re use of deadly
force. I assume you don't
mean to suggest that many/most Internet users are in physical jeopardy
as a result of nation state surveillance, right? Is your argument that
_every_ user of the Internet should incur performance and convenience
penalties to provide cover for the very, very tiny fraction of users who
are in real, physical jeopardy as a result of such surveillance? I don’t
think that those of us who develop Internet standards are in a position
to make such tradeoffs.
There are legitimate concerns that arise if we push the envelope wrt
traffic flow security on
a wide scale basis, e.g., bandwidth consumption (especially in mobile
environments), battery power , user-perceptible performance (traffic
engineering based on traffic type), and even reliability (load balancing
performed by devices not so close to servers.) That’s why I’m
comfortable offering mandatory-to-implement security features in
standards, but not mandatory-to-use security features.
Perhaps. But unless one accepts it as a principle, one is doomed to build
surveillance-friendly networks.
I guess we disagree about the relative threats to personal privacy, and how
such threats
are perceived by most users. I base my perception of the security-privacy vs.
convenience and
performance tradeoff based on online habits in contexts where folks clearly
sacrifice privacy to commercial concerns on a massive basis.
I've been enterprise IT. And enterprise security. Most of their security
problems
come form their own people abusing the loopholes. Sure, the IT department is
lazy.
But once the "generally accepted best practices" require e2e, they'll play
along. remember,
corporate policies are driven by generally accepted best practices such as GAAP
for
accounting. Note that, at least under US law, the management of a corporation
is subject
to legal attacks from shareholders for losses related to the failure to deploy
generally
accepted best practices for information security.
I agree that companies do tend to follow the heard, for the reasons you
suggest. But, that does
not mean that we are in a position to tell enterprises that their concerns wrt
monitoring
internal traffic, debugging, etc. are less important that a (well-intentioned)
desire to thwart
surveillance at a global level. Again, it's the mandatory-to-use vs. implement
issue.
A listing of best practies [sic] is here:
http://www.wpi.edu/academics/CCC/Policies/bestpractices.html
Note that they're written by people like CDT (an officer of which edited our
privacy RFC),
NIST, and other bodies that we influence.
The IETF does not generally influence NIST or most of the other organizations
that are sources
for the cited documents. (The IETF has often adopted NIST standards for our
security RFCs.) Also,
the WPI URL lists security best practices documents from dozens of sources, not
just NIST or CDT.
Should it? Who funds BBN, anyhow? What's your motivation for making choices
that increase
surveillance?
I'm pretty sure we get all our money from the GFF (Good Funding Fairy) ;-).
I have no idea what triggered this nasty comment in response to my observation
that we have offered
TFS options (e.g., in ESP) that have never been used. I was the designer of the
TFS features of
ESP, so it’s absurd for you to suggest that I am “making choices that increase
surveillance.”
Yeah, that's an ad hominem attack . But we're going to get a lot of those, and
need to have
a great deal of confidence in our answers. "Nobody wants security" is probably
not a good
enough answer … Nor is "Security costs too much", especially until the costs
have been
more completely quantified -- including the costs of making systems that nobody
will buy
because they don't want to spill their guts to our friends at Meade. Even the
least suspicion
of pro-surveillance bias needs to be avoided for the results to be credible.
So, your reasoning appears to be that, because “we” may the target of future ad
hominem attacks,
you are justified in engaging in one now. Do you now what a non sequitur is?
Ah yes, the old "if we build E2E, nobody will use it" argument. I find that to
be an
extremely suspicious argument, but recognize it and its kin have, for many
years, led
us down a rabbit-warren of bad choices, resulting in the problem we have today.
I am the author of several standards (e.g., RFC 4301, 4302, 4303) that enable
e-t-e security.
If I didn't hope people would make use of such technology I would not have
spent a lot of time
on these documents. You state that you find my comments with respect to use of
security “suspicious.”
I find your comments about an absolute need to impose Internet standards that
mandate_use_ of
security to be amazingly hubristic, especially from someone with NO security
RFCs to his credit.
Regrettably, and as a former Cisco employee, I can tell you that folks there
also face
certain pressures from state actors. I'm sure this is true of most folks. David
may be a
saint. He might be a devil. But as an external party lacking the expertise, I
have no way of
telling if his position is biased against my objectives.
I agree that you are “an external party lacking expertise.”
So unless we have widespread review, from people likely to be in the influence
of multiple
and conflicting actors, we really haven't had a review. How widespread? I'm not
exactly sure
-- but it means more than one review, from more than one company, from more
than one sector,
and from more than one nation-state at a minimum. Trust is really hard; our
best substitute
is a very widespread consensus.
I review a fair number of security-themed papers for journals every year. Most
are terrible.
I don't think the IETF needs inputs from folks like he authors of those papers.
“Very
widespread consensus” is not a substitute for high quality review by competent
people. But, this
aspects of our discussion is largely irrelevant, since the IETF process does
acquire inputs
from a wide range of folks as we evaluate and progress standards.
Arguably, the mode that we've operated in for many years has given us a rather
bad current
situation. Perhaps we should reassess "good enough".
IWe have standardized a pretty reasonable set of security mechanisms, many of
which are
either not used or have been badly implemented, or both. Some of the sources of
significant
vulnerabilities have arisen because of decisions by actors external to the
IETF, e.g., vendors and
service providers, for business reasons. (One good example is provided by he
PKI trust model
implemented in browsers, but there are many, many more examples.)
Could we do better? Yes, in some areas we could have better standards.
Should we mandate_use_ of additional, possibly burdensome security mechanisms
by
all Internet users? I think not.
Steve
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
