Zero Trust Networks

Chapter 10. The Adversarial View

Most formal proposals in the technology industry include a section commonly known as “security considerations.” In fact, the IETF mandates a security consideration section for all submitted RFCs.

This section is crucial for many reasons. First, it clearly communicates potential pitfalls, dangers, and caveats. This is extraordinarily important during the implementation and deployment phases, as it will help to ensure that the operator arrives at a design which retains the security properties that the system was originally designed for.

Second, it demonstrates that the authors have put good thought into the ways in which the system can be attacked. It is far too easy to design a seemingly secure system which harbors a major vulnerability just under the surface. And finally, it sets the stage for discussion on how to best approach and manage the security risks presented. As a result, including a security considerations section is generally considered best practice. Some might even view the work as deceptive without such a section, since it might indicate that the authors are trying to push a known-weak technology.

Even the strongest proposals will have some security considerations. For instance, the latest RFC for the TLS protocol has 12 pages worth. It is important to understand that a system is not inherently insecure simply because there are security considerations associated with it; rather, it should be a sign that the system as a whole is