Protocol codesign

• Authors: Victoria Stavridou
• Venue: Proceedings of the 11th international conference on Security Protocols
• Year: 2003

This afternoon I'm going to talk to you about some work that we're doing on protocol design. This is actually Hassen Saidi's work; he spoke a little about this at the workshop here a couple of years ago and since then there's been quite a bit of progress. There are many challenges in the design of protocols; both the ones that we have today, and the ones that we need to evolve in the future. The conversation here this morning clearly identified those challenges, so I don't think I will preach here. But protocols are changing, and they're changing form in a couple of ways. They're changing by moving from the traditional place where one would do a protocol – from the network layer into the application layer – because the applications themselves are changing. Also our expectations of the technology that we develop for security applications has changed. For example, now we talk about intrusion tolerance; it's not enough to build something that is secure, I also want to build it in such a way that even if attackers succeed in penetrating it it will still provide some level of service. In that one might see the influence of fault tolerance: today's applications not only have traditional security requirements, but also things that have not traditionally been thought of as properties security protocols would implement. Nonetheless, now that we're putting them together the protocols have got to do both jobs. New applications need new protocols and sometimes that happens, but sometimes known protocols get re-engineered (sometimes well, mostly badly), and what tends to happen is that unless one is very, very careful and thoughtful and systematic about the way that protocols are re-engineered or composed, you may end up actually making things worse. Rushby has a good example about putting together two protocols, a fault tolerant protocol and a security protocol, and ending up with something that is neither secure nor fault tolerant. We've been driven not just by changes in the application, but also by this variety of properties that they have to implement, so we need to understand the interactions of the properties, and the subtleties that those interactions entail, and the impact that those subtleties have on the final product: by and large this is a darn hard thing to do.