Subject: RE: OPEN ISSUE: Standards Track

From: <[email-masked]>
Date: Fri, 23 May 2003 08:27:31 +0300

Jari,

> 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.

Adding on to this, perhaps it would be prudent for
most new working groups should do a threats analysis
and perhaps even an analysis or review of existing 
security solutions, before protocol design.

John

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 22 May 2003 22:42:15 -0700

Hello John,

I'm afraid this may be getting away from the original point,
which is that there needs to be a way to boil a truckload
of water before we boil the ocean.

The idea of requiring a threat analysis and deployment
scenarios analysis is a pretty good way to raise the bar
way up into the stratosphere so that no work gets done.
Presumably you meant that this would come _after_
the problem statement and definition, followed by the
requirements analysis, all of which should (???) occur
before anyone is allowed to mention a solution.

Or did you mean that we could mention a solution
without having any protocol in mind, and then somehow
do a threat analysis on the solution without seeing any
protocol that might embody that solution?

I really don't think engineers work that way.
I think iterative and parallel development is best,
and testing interoperability all along the way.

Regards,
Charlie P.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 23 May 2003 09:30:10 +0300

> before anyone is allowed to mention a solution.

(This is starting to sound a lot like the operation of
the problem WG...)

I very much agree with you about boiling the ocean.
And about including interoperability and implementation
experience along the way. The current IETF mindset
resembles the waterfall software engineering model:
lengthy release cycle, a lot of new features in releases,
emphasis on planning, review, and quality control.

I agree that adding at least some amount of iterative
process thinking would be good. I view this mainly as
starting with a smaller set of functionality than
improving scalability of solutions at a later stage,
however. In short: we need to have scalable, secure,
and otherwise quality protocols. But we may not need
them to have all features. Looking at the planned
future work in the charters of the MIPv4/MIPv6/MIPSHOP
WGs, it looks like we are now using an iterative
and parallel approach. Very good!

--Jari

P.S. Here's an exercise for the day: calculate an
estimated completion date for the problem WG when it
starts with the following: (a) full enumeration
of all problems of the IETF, (b) banning discussion of
"running code" i.e. solutions, (c) enumeration of
all core values that may not be broken as a result of
modifications, (d) lengthy discussion about the
process-changing process. This will have to be
followed by a discussion which picks the problems
and solutions that will be solved, the development
of the detailed solutions, and getting them approved
and deployed.

---

From: Keith Moore <[email-masked]>
Date: Fri, 23 May 2003 09:15:27 -0400

> before anyone is allowed to mention a solution.
...
> and testing interoperability all along the way.

I don't know of any other field of engineering that doesn't try to
comprehensively understand and define the problem before declaring something a
solution.  That's not to say that potential solutions are never sketched out,
but they're not treated as anything other than rough ideas.

If we're going to call ourselves an Engineering organization maybe we should
actually do Engineering rather than guesswork.

And I realize that many participants in IETF have problems thinking like
engineers. Maybe we should find a way to either teach IETF participants to
think like engineers or to recruit participants who do understand the
discipline of engineering.