Re: [saag] Additions to RFC 3631?

[Steven Bellovin <[e-mail]>]

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

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.)
> 
> 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 <[e-mail]>
>> An: IETF Security Area Advisory Group <[e-mail]>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/saag
> 


		--Steve Bellovin, https://www.cs.columbia.edu/~smb