Re: [saag] Additions to RFC 3631?

Hi Steve, 

Thanks for your quick response. A few remarks inline: 

> Thanks for your comments.  I don't agree with all of them (more
> inline), but I should note that I have no plans to update 3631 myself.
> I'm working on another project; it occurred to me that this laundry
> list of protocols -- it's a fine characterization -- was a good
> starting point for my recommendations.
> 
> On May 23, 2012, at 8:42 00AM, Hannes Tschofenig wrote:
> 
> > Hi Steve,
> >
> > to me it is not clear who the target audience of the document is and
> what purpose it serves.
> >
> > The early part of the document contains a threat model discussion.
> That's good but I believe that the writeup in BCP 72 is more useful.
> >
> > There is a laundry list of security mechanisms in Section 3. Do you
> expect that someone who does not know these mechanisms already to go
> through this list and pick one for their new protocol design?
> 
> Up to a point, yes.  It's not useful for people who know nothing of
> security, and it's redundant for folks who do security for a living.
> It's useful, though, for people who know something of these mechanisms
> but are not sure which to use.

To give someone a suggestion who does not know anything about security I
would actually point them to http://tools.ietf.org/html/rfc4101 instead
of letting them look at security protocols. 

> >
> > Then, Section 4 talks about things one shouldn't do. Those are great
> suggestions but we actively do them today in the IETF. For example, I
> have been complaining about the work in the INTAREA were folks are
> define new ways to do IP address-based authentication in light of the
> widespread NAT deployments (see my comments to the list last year
> http://permalink.gmane.org/gmane.ietf.int/3016).
> 
> The fact that folks are still doing them doesn't mean that we were
> wrong when we wrote 3631, merely that folks haven't paid enough
> attention to it.  In retrospect, I suspect we should have tried
> publishing it as BCP; were I still an AD or on the IAB, I'd suggest
> that for any updated version.

You definitely have not been wrong but it would be nice if the documents
lead to some changed behavior as well. 

> >
> > As you stated on the mailing list:
> >> 3631 says "if you want to put security into a protocol,
> >> here are the best choices we have today".
> >
> > Is this really how we approach protocol design today? I don't think
> so.
> >
> > There are two classes of protocol designs:
> >
> > 1) Extensions to existing protocols (DNS, email, routing protocols,
> etc.)
> > There you have to work with what is available already and your
> choices are impacted by the deployment. The improvements tend to be
> minor and speed of deployment is slow.
> 
> Retrofitting security to an existing system is one of the hardest
tasks
> out there.  It's not even the deployment, it's the design choices
> already made that constrain things.  DNSSEC is a classic example.  No
> one loves it or even likes it, I suspect, but I don't know that it
> could have been better, given the basic structure and assumptions that
> date to the earl 1980s.

The problem is that you essentially have to "retrofit" various
components (not only security) into the system all the time since a
successful system evolves and there is no way to consider everything in
the first try. If you consider everything in the initial design then it
will not be successful since it is too complex for everyone to use.
Furthermore, in many cases we make assumptions about the main use cases
for our technology and it turns out that we are often wrong. Either the
development is not as exciting as we had planned or the work gets used
for something entirely different. I will comment on that issue more in
the mail to Stephen.  

> >
> > 2) For new protocol designs, many focus on using HTTP/HTTPS as a
> starting point. Almost all protocols I have seen have the need for
> offering the classical communication security features and TLS is the
> main building block. Everything beyond that is typically tough and
> quite difficult to describe in a generic fashion.
> 
> That HTTP[S] is a basic building block is a separate problem; it's the
> new waist of the hourglass...

Interesting that you mention that and it would probably warrant a
separate discussion. 
(see
http://tools.ietf.org/html/draft-tschofenig-post-standardization-02). 

> >
> > On top of that I am not even sure that the process we have for
> tackling security in the IETF is actually as successful as we would
> like it to be. We typically consider the security consideration
section
> writeup as the crucial part but I am wondering whether others had
> looked at the broader picture on where things went well and where they
> didn't. In fact, I would be far more interested to hear where the
> problems really are rather than producing another hitchhiker's guide
to
> IETF security protocols.
> 
> Is it perfect?  Of course not.  I do think it's significantly better
> than it was 10-15 years ago.

Definitely. 

> 3631 and BCP 72 (which my email archives show was initiated no later
> than 1999) were part of a process to improve the security of IETF
> protocols.  Another part was retargeting the security directorate to
> review all documents, and get at least some involvement early on in
> protocol design.  That part didn't work as well as I had hoped, at
> least back when I was AD, but it was far better than we'd had before.
> That effort, though, was a fair number of years ago.  I've been rather
> disconnected from the IETF since 2005; I don't know what the current
> real issues are.  I'll leave it to the current IESG to figure out what
> to do next.  A more systematic study would indeed be a good idea.  (I
> know from private conversations that the Security ADs have at least
> some thoughts on the subject.)

I certainly agree that the chosen path has lead to a significant
improvement and the combination of guidance combined with the process
and training has shown good results. 

We should probably open another discussion thread on this topic to hear
the feedback from others about their experience in various working
groups. 

Just one tiny remark: If you look at the HTTP authentication and TLS
security work in the IETF one could get the impression that everything
is great with Web authentication. A short write-up is here:
http://tools.ietf.org/id/draft-tschofenig-secure-the-web-01.txt

Ciao
Hannes

> >
> > In any case, I will not stop you from shipping an update (which I am
> not sure you can even do that given it is an IAB document) but I doubt
> that it will have the desired impact.
> >
> > Ciao
> > Hannes
> >
> > -------- Original-Nachricht --------
> >> Datum: Fri, 18 May 2012 22:31:39 -0400
> >> Von: Steven Bellovin <smb@cs.columbia.edu>
> >> An: IETF Security Area Advisory Group <saag@ietf.org>
> >> Betreff: [saag] Additions to RFC 3631?
> >
> >> Does anyone have any suggestions for additions or corrections to
RFC
> 3631?
> >> It looks to me like it's held up pretty well, save for newer
> versions of
> >> some of the protocols.
> >>
> >> 		--Steve Bellovin, https://www.cs.columbia.edu/~smb
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> saag mailing list
> >> saag@ietf.org
> >> https://www.ietf.org/mailman/listinfo/saag
> >
> 
> 
> 		--Steve Bellovin, https://www.cs.columbia.edu/~smb
> 
> 
> 
> 
> 
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag