Security and Pervasive Monitoring

So the reports about large-scale monitoring of Internet traffic and users disturbs us greatly.  We knew of interception of targeted individuals and other monitoring activities, but the scale of recently reported monitoring is surprising. Such scale was not envisaged during the design of many Internet protocols, but we are considering the consequence of these kinds of attacks.

Of course, it is hard to know for sure from current reports what attack techniques may be in use.  As such, it is not so easy to comment on the specifics from an IETF perspective.  Still, the IETF has some long standing general principles that we can talk about, and we can also talk about some of the actions we are taking.

In 1996, RFC 1984 articulated the view that encryption is an important tool to protect privacy of communications, and that as such it should be encouraged and available to all.  In 2002, we decided that IETF standard protocols must include appropriate strong security mechanisms, and established this doctrine as a best current practice, documented in RFC 3365. Earlier, in 2000 the IETF decided not to consider requirements for wiretapping when creating and maintaining IETF standards, for reasons stated in RFC 2804. Note that IETF participants exist with positions at all points of the privacy/surveillance continuum, as seen in the discussions that lead to RFC 2804.

As privacy has become increasingly important, the Internet Architecture Board (IAB) developed guidance for handling privacy considerations in protocol specifications, and documented that in RFC 6973. And there are ongoing developments in security and privacy happening within the IETF all the time, for example work has just started on version 1.3 of the Transport Layer Security (TLS, RFC 5246) protocol which aims to provide better confidentiality during the early phases of the cryptographic handshake that underlies much secure Internet traffic.

Recent days have also seen an extended and welcome discussion triggered by calls for the IETF to build better protections against wide-spread monitoring.

As that discussion makes clear, IETF participants want to build secure and deployable systems for all Internet users.  Indeed, addressing security and new vulnerabilities has been a topic in the IETF for as long as the organisation has existed.  Technology alone is, however, not the only factor. Operational practices, laws, and other similar factors also matter. First of all, existing IETF security technologies, if used more widely, can definitely help.  But technical issues outside the IETF’s control, for example endpoint security, or the properties of specific products or implementations also affect the end result in major ways. So at the end of the day, no amount of communication security helps you if you do not trust the party you are communicating with or the devices you are using. Nonetheless, we’re confident the IETF can and will do more to make our protocols work more securely and offer better privacy features that can be used by implementations of all kinds.

So with the understanding of limitations of technology-only solutions, the IETF is continuing its mission to improve security in the Internet.  The recent revelations provide additional motivation for doing this, as well as highlighting the need to consider new threat models.

We should seize this opportunity to take a hard look at what we can do better.  Again, it is important to understand the limitations of technology alone. But here are some examples of things that are already ongoing:

• We’re having a discussion as part of the development of HTTP/2.0 as to how to make more and better use of TLS, for example to perhaps enable clients to require the use of security and not just have to react to the HTTP or HTTPS URLs chosen by servers.
• We’re having discussions as to how to handle the potentially new threat model demonstrated by the recent revelations so that future protocol designs can take into account potential pervasive monitoring as a known threat model.
• We’re considering ways in which better use can be made of existing protocol features, for example, better guidance as to how to deploy TLS with Perfect Forward Secrecy, which makes applications running over TLS more robust if server private keys later leak out.
• We’re constantly updating specifications to deprecate older, weaker cryptographic algorithms and allocate code points for currently strong algorithm choices so those can be used with Internet protocols.

And we are confident that discussions on this topic will motivate IETF participants to do more work on these and further related topics.

But don’t think about all this just in terms of the recent revelations.  The security and privacy of the Internet in general is still a challenge even ignoring pervasive monitoring, and if there are improvements from the above, those will be generally useful for many reasons and for many years to come.  Perhaps this year’s discussions is a way to motivate the world to move from “by default insecure” communications to “by default secure”.  Publicity and motivation are important, too. There is plenty to do for all of us, from users enabling additional security tools to implementors ensuring that their products are secure.

In the Vancouver IETF meeting, there will be time dedicated to discuss this, and we ask that those interested in working on this topic contribute to the analysis and develop proposals in this area.  Those contributions are very welcome and can start now and continue in Vancouver and beyond.

Relevant mailing lists (from most specific to most general) include:

• The perpass mailing list (perpass@ietf.org), recently set up to consider how the IETF ought react to pervasive monitoring
• The ietf security area mailing list (saag@ietf.org), for general security topics
• The ietf main mailing list (ietf@ietf.org), for general discussion