OPEN ISSUE: Standards Track

[Jari Arkko]

I will just say first that I agree with Steven's
explanation of the  reasons why AH/ESP were
inappropriate for securing binding updates to
random nodes in the Internet. For those that haven't
followed MIPv6 development I'll add that AH/ESP were
eventually replaced by an application specific security design
which deals with the specific dangers resulting from binding
updates, but does not require pre-arranged security associations
or global authentication infrastructure. Original MIPv6 didn't
actually have a security problem, IMHO; it was more of a
deployment problem. Yes, we have wasted two years but on
the other hand the amount of nodes you can run it against
has increased from one or few to the size of the Internet.
Not bad? Now all we need is for IPv6 to take off ... and
IESG to approve the documents this time. I'm trying to figure
out which one is more likely ;-)

But then back to the issues relevant for the problem
statement WG.

Raj said that earlier review from the security folks
would have helped. Perhaps, and such help is often
very useful and the IETF needs more cross-area
expertise. I'm all for it.

However, I'd like to present a slightly different opinion
about the way that security design in the IETF could work
better. Reviews may be a necesary but certainly not a
sufficient condition. The way I see it, there appears to
be a number of problems that we are facing:

- developed protocol specifications fail to take in
   account security in some manner, leading to security/
   approval/delay issues
- security mechanisms developed for various things
   don't get used in the field for various
   reasons, perhaps a key issue being once again
   deployment and configuration
- there are some hard problems that even the
   security experts are learning to deal with
- slow publication schedule for at least some of
   security features that the community would need.
- differing opinions about where we should be in
   the low "cost" vs. high security question.

So how could the IETF do better? I think a key element
for this is not (only) more frequent review from the few
security experts, but rather a better understanding
of the security issues by the other protocol designers.
Or making the security design more of an integral
part of the rest of the design for whatever we are working
on. This should include an understanding of the possible
security problems resulting from the planned feature.
Among other things, this understanding would help in choosing
security solutions that prevent the problems, and don't
do additional things that would require, for instance,
a global PKI. A number of documents by Steven,
Eric, and others exist to educate protocol designers
and we should use those documents, and write more. So:
we need more training.

As a result of better understanding of the security
issues in a feature, I suspect that we'd see less
"just authenticate everyone" approaches, and more
intelligence tied to the specific application, such
as cross-checking TLS-derived information with something
else at the application layer.

Secondly, we've talked about early architecture
design in this list. The security architecture
for protocol X would be a prime candidate for
inclusion in the architecture design section,
and should be reviewed early. Not when the bits
have been designed! No mandatory architecture
design early on, no early review possible...

Thirdly, it is really, really crucial to think about
deployment issues and how easy to use people find the
security mechanisms. All of us could use secure e-mail
but almost no one does. Why? And do the current secure
e-mail protocols deal with the real problems people are
having with e-mail? Why can't I think of more success
stories in security beyond one-sided TLS authentication,
SSH, and cellphone smart cards? IMHO we as a community
do not understand these issues well enough at the moment,
let alone have documented them somewhere. Yet this
seems a much more important issue for the world than
getting some documents approved by the IESG at t1 or t2.
Here's where I think the security area should probably
move a bit of its focus on. Less "policy" from admins,
less extra work for users, less reliance on non-existent
other stuff in the network.

My fourth point is that we need to be more honest about
the limitations of our security mechanisms, and faster
to get them updated when new algorithms come around etc.
Again some educational documents are needed for the
first part. (In some cases I suspect the educational
aspects would apply even to the folks developing the
particular mechanism...)

Finally, any problem in the process is amplified when
we try to do too large chunks of functionality in one
document. Unfortunately, this appears quite common in
today's IETF. Why? In addition to making the wrong
decision, there maybe a few other reasons behind this.
We appear not so good in incremental design. Reviewers
want to see the whole thing, to ensure that all aspects
have been taken care of. I agree with Charlie that we
shouldn't try to boil the ocean (though I may have a
different idea about the right way to split and phase
protocols). In general, the IETF tries to arrive at
a pretty perfect protocol for PS. We need security
and maybe even scalable security when a document becomes
a PS RFC, but we may not need all functions. Lets
start producing basic protocols with a series of enhancements
following them. And since someone will worry about the
"big picture" and how these pieces fit together,
we probably need again the architecture design document,
we need more detailed roadmaps than the current charters
are, and so on. And WGs need to realize that documenting
functions in separate specifications does not mean
that their pet features have been "left out".

--Jari