1. The need for better security considerations guidance
Dan Romascanu
(with Contributions from Andy Bierman and Pasi Eronen)
IETF meeting
Montreal, July 2006

2. Scope
Need for more clear and detailed guidelines for security sections in protocol documents
Discussed at the IESG retreat in May
What is the range of applicability of BCP 61 (RFC 3365)?
What's wrong with BCP 72 (RFC 3552)?
Some ideas for improvement

3. Is anything wrong?
About 35% of the DISCUSSes in the IESG documents review are security-oriented
based on Bill Fenner’s statistics and direct observation of the IESG meetings
many of them seem to be pretty fundamental, reflecting a gap between the level of understanding of the security requirements between protocol designers and security experts
They come very late in the process, especially if security reviews were not performed in the document prior the discussion in the IESG
Lack of consensus and consistency among security advisors
Especially when it comes to applying the latest standards which may be work-in-progress
RESULT
Frustrating last-minute delays in getting protocol documents approved
Lack of determinism in assessing how far a document is from completion
Perception that security is ‘black magic’ – cannot be solved in a rational manner, better try to finesse
Eventually – either ‘secure and late’ or ‘non-secure’ documents, and a lot of frustration and incertitude

4. What is the range of applicability of BCP 61 (RFC 3365)?
RFC Strong Security Requirements for Internet Engineering Task Force Standard Protocols
The principal problem is that RFC 3365 is too ‘high level’
E.g. – I do not know what to do with:
Yet we often require cryptographic technology to implement authentication and integrity of protocol messages. So if the question is "MUST we implement confidentiality?" the answer will be "depends". However if the question is "MUST we make use of cryptographic technology?" the answer is "likely".
It really needs some implementation notes
Including some sort of table to help a WG figure out which security feature requirements match which protocols to use

5. What's wrong with BCP 72 (RFC 3552)?
RFC Guidelines for Writing RFC Text on Security Considerations
Timeliness
A large number of references are obsoleted and updated
RFC2402 obsoleted by 4302, 4305
RFC2535 is obsoleted by RFC4033, RFC4034, RFC4035, Updated by RFC2931, RFC3007, RFC3008, RFC3090, RFC3226, RFC3445, RFC3597, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845 
2406 is Obsoleted by RFC4303, etc., etc.
(not to speak about work-in-progress – e.g and 4366 was referred in security reviews months before publication)
over-emphasizes communications security. While the "Internet threat model" (bad guys in the network between two-or-more honest parties) in Section 3 is of course very traditional for cryptographic protocols (like IPsec and TLS), it maybe outright misleading for most IETF protocols.
example: in RFC 4072 (Diameter EAP Application) security considerations section, the communication security threats are dealt with a single paragraph. The rest of the five _pages_ deals with threats arising from authenticated Diameter peers.
Section 5 - Writing Security Considerations Sections is extremely ‘thin’
It is already thin wrt. Sections 3 (Internet Threat model) and Section 4 (common issues – actually requirements) and does not help a document author understand what is expected
Not everything fits into a Security Considerations section
Security needs to be embedded in the design of the protocol
Extended security sections or separate documents (e.g. RFC 4261)

6. Some ideas for improvement
Update RFC 3552
Create a ‘living’ Web version that can be updated permanently to reflect later security documents
Try to catch things earlier
Enforce mandatory security reviews prior to the IESG review for any new protocol document
early review process
Increase the level of determinism by better documenting the security requirements
A guidelines document about how to perform security reviews which could be used by the document authors to understand what they would expect
Crafted on the example of what RFC 4181 is for MIB reviewers and MIB documents authors
Adapt security requirements to the scope of the protocol
Routing, signaling, provisioning, monitoring – each have different needs
Better educational materials
Revise EDU security material so that much more information is provided about
when and how does strong security apply?
‘how to design security into protocols’? - today’s ‘Security Considerations Considerations’ section does not even mention RFC 3552!