[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IETF: Security and Pervasive Monitoring


Security and Pervasive Monitoring

The Internet community and the IETF care deeply about how much we can trust
commonly used Internet services and the protocols that these services use.
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

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

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 ([email protected]), recently set up to consider how
the IETF ought react to pervasive monitoring

The ietf security area mailing list ([email protected]), for general security

The ietf main mailing list ([email protected]), for general discussion

Jari Arkko, Chair of the IETF and Stephen Farrell, IETF Security Area


This entry was posted in IETF on 2013/09/07.