Re: [perpass] Howdy!

[Stephen Kent <[e-mail]>]

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