OPEN ISSUE: Standards Track

[Charlie Perkins]

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.




john.loughney at nokia.com wrote:

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