Re: [saag] should we revise rfc 3365?

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

Regarding the text below I believe I am suggesting to investigate the
cases where the security deployment did not happen as planned. We are
jumping to conclusions far too quickly and the reasons for why things
did not work out as planned may have many reasons - many of them may not
be so obvious. For some reason we often believe another document will
fix the problem.

In the IAB, for example, we did some reviews of protocols (with respect
to privacy) and got some interesting insights as to what the problems
were with the way we approached privacy in the past. I would be
surprised if nobody had ever looked at the details of how the work on
security evolved for specific protocols. 

> > I also noticed that some protocols do not necessarily have a
realistic
> > security solution. The reasons are, however, often complex.
> >
> > SIP, for example, has taken quite a different deployment route than
> many
> > of us had thought and consequently security had been impacted by
this
> > development as well. I don't even know where to start when talking
> about
> > the challenges for SIP security. There is a huge mixture of business
> > models (e.g., SBCs, interconnection models), technical & user
> interface
> > challenges, the attempt to replicate the PSTN (with all it the
> features)
> > and the rise of the Web.
> >
> > It is difficult to say what the right time is to conclude that
> something
> > had gone wrong and needs to be fixed or whether the time for a
> specific
> > protocol just had not come yet. I have this discussions periodically
> > with the mobility guys (and there is plenty of exciting security
work
> > had been done with essentially zero deployment). Mobile IP is a
> > particularly interesting case since the security components are the
> > heaviest part in the protocol and the question arises whether the
> choice
> > of security technology has actually lead to the lack of deployment.
> 
> So are you arguing that we ought stage "compliance" with
> 3365 somehow? Even for standards track specs? I think I'd
> push back against that on the basis that it'd be hard to
> believe a load of WGs would properly consider security
> but not produce the goods until after their main work is
> done. It'd also be bolt-on security as well I guess, which
> often turns out badly. (Though fictional security is also
> maybe just as bad.)