make privacy via encryption the default at every level, or perhaps
even mandatory, and to expect it to work. Key management has to be
seamless and automatic, and the software and hardware have to be
trusted. Let's button up the net and protect our communication from
prying eyes, whether they be ISPs wanting to charge us for "high
value" traffic, governments wanting to gather intelligence, or
others.
As a goal statement, the above seems to me one of the better and more
concise summaries of the IETF community 'tone' right now. And it
certainly is extremely appealing.
And it's probably reasonable as a goal statement, as long as there is an
understanding of the challenges in achieving it. My own concern is less
with whether, for any specific security enhancement, we are "expecting
the encryption to work" but with what it will cost and whether it will
be useful.
What I've noticed in most/all of the discussions surrounding the privacy
concerns is a general lack of attention to limitations, tradeoffs or
even outright barriers. Discussions are being conducted as if every
kind of security mechanism is cost-free, easy and useful.
A ready response to such concerns is that the community is interested in
a "belts and suspenders" approach. The problem with invoking that
reference is that the functions of a belt and a suspender are
well-understood, the use is cheap and easy, and the relationship between
the two is also well-understood.
None of those properties apply for Internet-scale, mass-market
application of widespread security mechanisms. To date, the only
mechanisms that qualify for this are, indeed, https to many (but not
all) servers over the open Internet, and variations of SSL use with IMAP
or POP, within subscribed environments. I suppose use of IPSec for
VPNs, within a relatively small range of enterprises also qualifies.
But given the scope of what is currently being discussed, I'll suggest
that this is actually a rather modest base of operational experience.
Security, in particular, can be extremely expensive. I'm not so worried
about computational cost -- although it can be significant -- but ops,
admin and management cost for security are typically significant.
The reality is that these mechanisms often are expensive and sometimes
are quite literally beyond the state of the art. (Not just beyond
current products, but actually beyond what research has yet
demonstrated.) The most notable piece that is beyond the state of the
art is the entirely appropriate reference to neeing key management to be
seamless. Sorry, but we don't know how to do that.
So, what am I suggesting?
I'm suggesting that proposals be diligent in considering reasoanble
drawbacks to implementation of the proposal. How will an added
mechanism be useful? What sorts of attacks will it prevent? What is
the evidence that such attacks are already happening? (That an attack
hasn't been happening doesn't mean it should be ignored, but it does
mean it is not known to be an immediate threat.) What are the OA&M
barriers to adoption and use? What are the possible interaction effects
with other security mechanisms? What is the experiential base for the
proposal and how will widespread deployment challenge that?
In other words, please stop looking only at ideal benefits and start
considering serious pragmatics.
d/
ps. FWIW, I'm also concerned that nearly all discussions are about
protecting one-hop transfers, with no real concern for exposures at the
relaying point, where most violations actually occur...
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net