[Model-t] Model-t Perspective and Method Questions

["Rezaki, Ali (Nokia - DE)" <[e-mail]>]

Hello!

This is a short contribution about the perspective and method of the Model-t efforts, informed by the drafts submitted to the recent IAB DEDR workshop and the discussions so far on the Model-t mailing list:

Starting from the basics of BCP 72, would it be fair to say that BCP 72 helps RFC authors to determine the security risks for users of the protocol content they are producing? BCP 72 does this by providing a catalog of threats that communications and systems could face and asks the RFC authors to design protocols without vulnerabilities that could be exploited by these threats, thereby avoiding the associated risks. Any residual risks due to unmitigated vulnerabilities are to be documented as part of the “Security Considerations” section.

BCP 72 informs RFC authors of the threats they should consider. It includes an Internet threat model and definitions. Definitions and assumptions of end-systems and the communications channel between them play a key role in the resulting threat model. BCP 72 assumes that end-systems are generally uncompromised while the communication channel between them most likely is.

A question for the Model-t discussion is: has the threat landscape changed significantly enough, to warrant the creation of a new Internet threat model, so that this can be used to inform RFC authors, enabling them to mitigate vulnerabilities in their protocols that could otherwise be exploited by these new sets of threats.

As the definitions of end-systems and communication channels play a central role in BCP 72, it is worthwhile to see what changes happened in these domains over the years. For example, the protocol stacks of end-systems are significantly affected by the interplay among roots-of-trust, increased number of virtualized layers and applications such as browsers, with which most of the services used on and between the end-systems and over the Internet and in the cloud are accessed - and often using E2E encryption. Considering these changes, where would an end-system begin and a communication channel end? How are these changes co-existing with the end-to-end principle? Do these developments change the definitions used in BCP 72 and the associated assumptions, also impacting the vulnerabilities and threats accounted for in existing IETF protocols?

To make things more concreate, it might be helpful if examples could be given of attacks that exploited vulnerabilities in IETF protocols that could not have been prevented by the current threat model in BCP 72. Cases where an updated BCP 72 could address a previously unaccounted for threat and enable the mitigation of a vulnerability and risk in an IETF protocol would have a clear significance for Model-t efforts and would help define criteria for potential changes. If RFC’s had vulnerabilities since they did not take BCP 72 recommendations into account, that’s a different lesson outside of Model-t scope. Vulnerabilities resulting from specific implementation failures not found in the RFC specs would also be excluded. The IETF protocols already created and being worked on give a rather well-defined scope to this effort.

Beyond making IETF protocols less vulnerable, IETF security community also has the aim of creating security protocols to make Internet communications, processes and assets less vulnerable, as seen with the work on TLS versions over the years, among others. The perceived threat model would have a bearing on what security measures are being developed at the IETF. These security measures would also be in areas already being covered by IETF work. For example, in the case of TLS, IETF had already been developing Transport Layer protocols and securing the Transport Layer was also within that scope. 

This also follows from the horizontal nature of security, where area specific vertical expertise is needed to create effective security mechanisms. Therefore, if IETF has been working on topics in a specific area, it would also be in a good position to mitigate the vulnerabilities emerging from that area. In this respect, the security threat model discussion would be informed by any IETF-wide strategy on scope and coverage of IETF work. Has the scope of IETF work been evolving and if so, is there a set of criteria used? For example, would it be helpful to give a perspective on how IETF started working groups such as TEEP, RATS and SUIT, which seem to have additional benefits for securing end-systems beyond their relation to communications security?

If this perspective would make sense, would it be helpful then to initially work on:

1. Examples of attacks that exploited vulnerabilities in IETF protocols that could not have been prevented by the current threat model in BCP 72, and in what way the threat model in BCP 72 could be modified to address these vulnerabilities?

2. Requesting information from related IETF contributors about a map of areas that IETF considers to be in scope for its work, and its evolution over the years, also identifying the underlying principles?

Looking forward to feedback and discussions here and at IETF 106 in Singapore.

Thanks very much for your attention.

Cheers,

Ali