Hannes Tschofenig

Personal blog about various IETF and Internet related activities

Aug 14

Various groups in the IETF currently standardize technology for use with constrained devices and the choice of hardware impacts the design of Internet of Things (IoT) systems. To provide guidance RFC 7228 “Terminology for Constrained-Node Networks” defines three classes of devices depending on their RAM and flash memory size. Class 0 characterizes devices that have less than 10 KiB of RAM and less than 100 KiB of flash memory and RFC 7228 adds “… most likely they will not have the resources required to communicate directly with the Internet in a secure manner.” For others even class 2 with ~ 50 KiB of RAM and ~ 250 KiB of flash memory is too constrained.

With the increasing commercial interest in IoT the question about a reasonable hardware configuration surfaces again and again. At the IETF#90 ACE meeting I offered to bring a hardware expert along. Peter Aldworth, a hardware engineer with more than 19 years of experience, will lead the discussion at an upcoming webinar.

The question about the suitable hardware platform has been particularly interesting in context of security discussions since security protocols tend to consume a fair amount of resources. Since security is often added to an existing design, as an afterthought, various deficiencies are built-in from the get-go.

The webinar will be held either during the first or second week in September. Please indicate your availability in this poll, if you are interested in this discussion.

To give you a flavor of the discussion consider this piece of hardware, the Nordic nRF51822-mKIT. It is an example of a recently released Internet of Things development board offering a Bluetooth 4.1 stack. This board allows engineers to create Bluetooth Smart peripherals using the mbed development environment. It uses the ARM Cortex M0 processor with 256kB flash and 16kB RAM. The ARM Cortex M0 is an example of a frequently used processor in Internet of Things appliances.

May 14

Mid 2013 I posted a summary about ongoing efforts on privacy in the IETF and I got a lots of good feedback. ISOC even published an extended version of the write-up at http://www.internetsociety.org/articles/ietf-privacy-update. Since summer 2013 a lot happened with regards to security and privacy.

Here is another short update based on activities I have seen. Let me know if I miss something.

Pervasive Surveillance 

With the revelations provided by Snowden a mailing list was created to have a venue for IETF security and privacy experts to discuss the implications of various news articles. This mailing list, called “Perpass List“, was established and triggered a rich discussion about what IETF protocols we need to look into. It is difficult to summarize all the discussions but the archives are available. As a side-effect of the discussion the “Using TLS in Applications” (UTA) working group was created to provide guidance for use of TLS in HTTP, XMPP, email, etc.  An important document discussed in this group provides recommendations for secure use of TLS/DTLS. Meetings at the London IETF meeting also discussed various ideas in more details, for example the desire to encrypt DNS exhanges (see http://www.ietf.org/proceedings/89/dnse.html).

The discussions in the IETF about the Snowden revelations were intense. I doubt that any other standardization organization saw a similar volume of discussions.  Quite naturally the Internet Architecture Board (IAB) used this as an opportunity to scheduled the pervasive monitoring topic as a plenary topic and invited several experts, including Bruce Schneier. Details about the plenary (including a video recording) can be found at http://www.ietf.org/media/2013-11-07-internet-privacy-and-security.html. Due to a job change I was unfortunately not able to attend the meeting myself but the plenary lead to a great discussion and resulted to good community feedback. Following the plenary, an IETF draft was produced to capture the feedback from the IETF community. The main message of <draft-farrell-perpass-attack> is rather simple:

“Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.”

As a follow-up action a workshop was organized. The workshop was called Strengthening the Internet Against Pervasive Monitoring (STRINT) and slides, position papers, and a short transcript can be found at https://www.w3.org/2014/strint/. The event was well attended and the position paper are of great quality. In the meanwhile a first version of the workshop report has been published that describes the conclusions:

“1. Well-implemented cryptography can be effective against pervasive monitoring (PM) and will benefit the Internet if used more,  despite its cost, which is steadily decreasing anyway.

2. Traffic analysis also needs to be considered, but is less well understood in the Internet community: relevant research and protocol mitigations such as data minimisation need to be better understood.

3. Work should continue on progressing the PM threat model draft [I-D.barnes-pervasive-problem] discussed in the workshop.

4. Later, the IETF may be in a position to start to develop an update to BCP 72 [RFC3552], most likely as a new RFC enhancing that BCP and dealing with recommendations on how to mitigate PM and how to reflect that in IETF work.

5. The term “Opportunistic” has been widely used to refer to a possible mitigation strategy for PM. We need to document definition(s) for this term, as it is being used differently by
different people and in different contexts. We may also be able to develop a cookbook-like set of related protocol techniques for developers. Since the workshop, the IETF’s security area has taken up this work, most recently favouring the generic term “Opportunistic Security” (OS) [I-D.kent-opportunistic-security].

6. The technical community could do better in explaining the real technical downsides related to PM in terms that policy makers can understand.

7. Many User Interfaces (UI) could be better in terms of how they present security state, though this is a significantly hard problem. There may be benefits if certain dangerous choices were simply not offered anymore. But that could require significant co-ordination among competing software makers, otherwise some will be considered “broken” by users.

8. Ways to better integrate UI issues into the processes of IETF and W3C needs further discussion.

9. Examples of good software configurations that can be cut-and-paste’d for popular software, etc., can help. This is not necessarily standards work, but maybe the standards organisations can help and can work with those developing such package-specific documentation.

10. The IETF and W3C can do more so that default (“out-of-the-box”) settings for protocols better protect security and privacy.

11. Captive portals, [6] (and some firewalls, too) can and should be distinguished from real man-in-the-middle attacks. This might mean establishing common conventions with makers of such middleboxes, but might also need new protocols. However, the incentives for deploying such new middlebox features might not align.”

As the reference indicate there have been some high-quality contributions, such as threat description, better terminology, that have been submitted to the IETF and are work in progress.


Engineering Privacy into Internet Protocols

The IAB privacy program has been working on the privacy consideration document and it has been published in RFC 6973. As a follow-up action a privacy tutorial was scheduled and held for the first time. Here is the announcement text distributed before the London IETF meeting (March 2014):

Privacy, as with security, has received increasing attention over the last few years as the number of security incidents and privacy violations increased. While security guidance has been offered in RFC 3552 and has been part of the IETF education tutorial for many years privacy related guidance has only been available recently with the publication of RFC 6973. This tutorial aims to provide the audience a brief overview of the privacy threats that engineers may encounter during their protocol work.

A core part of RFC 6973 is on offering guidance, i.e., a set of questions an engineer should ask himself or herself when designing new protocols or protocol extensions to take common privacy concerns into account.

The slides are available here and here. The audio/video recording was, unfortunately, corrupted. I will try to re-create one to make the content available to a wider audience.


The discovery of a severe security vulnerability in the implementation of the TLS protocol (in OpenSSL) illustrated a number of problems in the way how implementations of standards are produced. A lot can be said about what went wrong and there are various ideas about what can be done in the future to avoid similar problems (or at least to communicate them better). To keep it short I would like to point to a great article written by Monika Ermert for the Internet Policy Review, a journal on Internet regulation.


HTTP 2.0 & the “Trusted Proxy”

As mentioned in my summary last year one exciting development in the IETF is happening in the applications area with HTTP 2.0. With the discussions about pervasive surveillance the desire to provide an always-on security for HTTP 2.0 was raised and this would obviously make “deep packet inspection” by Internet service providers and enterprise networks more difficult. Hence, various companies (which are deploying these types of devices) have started to suggest proposals (e.g., draft-loreto-httpbis-trusted-proxy20 and draft-mcgrew-tls-proxy-server) for building a backdoor into Transport Layer Security (TLS) to terminate security somewhere in the middle of the network to inspect the traffic. Needless to say that this triggered some discussions (also at the STRINT workshop, at the privacy tutorial, and at various IETF mailing list). As an example take a look at Section 5.7 of draft-iab-strint-report and at the perpass mailing list.

TLS 1.3

The work on the new version of Transport Layer Security is ongoing and in the meanwhile progress has been made with the availability of a more detailed working draft. Requirements and use cases are being brought forward and support for privacy protection (and protection against pervasive monitoring) are brought forward. Particularly interesting are the discussions related to the use of cryptographic algorithms, which has lead the IRTF Cryptographic Research Group (CFRG) becoming more active. A recent interim meeting from the CFRG meeting was dedicated to the discussion of Elliptic Curve Cryptography (ECC) has shown in this renewed interest. Here is a link to an email from the co-chair David McGrew about the criteria for choosing a new ECC mechanism.


Mar 14

The privacy program of the Internet Architecture Board (IAB) has been working on a privacy tutorial for some time already and at the last IETF meeting in London I had the honor to present the work to the wider IETF community. The tutorial provided a sneak preview to a document we published last year, namely RFC 6973.

Privacy, as with security, has received increasing attention over the last few years as the number of security incidents and privacy violations increased. While security guidance has been offered in RFC 3552 and has been part of the IETF education tutorial for many years privacy related guidance has only been available recently with the publication of RFC 6973. This tutorial aims to provide the audience a brief overview of the privacy threats that engineers may encounter during their protocol work.

A core part of RFC 6973 is on offering guidance, i.e., a set of questions an engineer should ask himself or herself when designing new protocols or protocol extensions to take common privacy concerns into account.

The slides (PDF and PPT) are available. We also produced an audio recording of the session but unfortunately the audio quality is quite bad. I might just add audio to the slide deck myself and share it with the community.

Let me (us) know whether you find our approach useful. It is certainly not an easy checklist and requires a lot of thinking by the engineering designing the system but we couldn’t come up with another approach that covers the wide range of standardization activities the IETF is undertaking.


Mar 14

At the last IETF meeting early March in London I had the pleasure to co-chair the Authentication and Authorization for Constrained Environments (ace) BOF with Kepeng.
The picture of the flyer we distributed during the meeting should give you a rough idea what the topic is about.


(We are also working on the charter text that provides more details. The latest version can be found here and it is discussed on this mailing list.)

Here is my high-level summary of the BOF, which went pretty well (IMHO).

In a nutshell, we are trying to standardize an authentication and authorization protocol for use with constraint devices that makes use of a trusted third party.

In preparation for the BOF we scheduled a few tutorials about relevant technologies. Slides and recordings of the presentations are available.

  1. Kerberos (by Thomas Hardjono): Slides and Recording
  2. OAuth (by Justin Richer): Slides  and Recording
  3. “PKI/Certificate Model” (by Sean Turner): Slides and Recording
  4. AAA (by Lionel Morand during the IETF EDU session): Slides

Note: .arf files are Webex recordings. You might need to use a Webex player. See http://www.webex.com/play-webex-recording.html

UPDATE: We scheduled the ABFAB tutorial on April 22nd; the slides and recording are also available for download.

Sep 13

Many have been wondering about government spying activities on Internet communication and of course everyone is puzzled what to do about it. More specifically, who should do what for certain applications (since the application behavior is quite different).

I wrote down my thoughts in a presentation given to data protection authorities and I wanted to provide a bit more context to understand the slide deck. It also want to illustrate that there are various challenges (even when thinking about a single application, namely VoIP communication).

The Background

The International Working Group on Data Protection in Telecommunications (IWGDPT), which consists of mostly data protection authorities (DPAs) and similar organizations (e.g., the FTC) from all over the world, has published a Working Paper on Privacy and Security in Internet Telephony already in September 2006 to reach a common understanding of challenges that will arise with the introduction of VoIP technology from a data protection point of view. DPAs enforce privacy laws but they are not the only agencies able to do that. The recommendations are largely addressed to VoIP service providers and also to manufacturers of software and hardware. The recommendations are sound but were written at a time when most of the VoIP deployment was still at an early stage.

In the meanwhile VoIP deployment has increased substantially and even to an extend that some predict the end of the Plain Old Telephony System (POTS) in various regions, as discussed at the technical plenary of the Internet Architecture Board in March 2013. The plenary material can be found here. In practice it turns out that many over-the-top VoIP providers (and providers that provide real-time communication services like instant messaging, real-time text, and video) fall under a different regulatory regime than classical telecommunication companies (such as AT&T, Verizon, BT, Vodaphone). Consequently, they operate under different rules than the classical telcos with respect to telecommunication secrecy, emergency services, accessibility requirements, etc. Many over-the-top VoIP providers, such as Skype, don’t want to become electronic communications operator. Of course, just changing laws to apply the telecommunication laws also to over-the-top provider does not work since the environment is very different.

A few years have passed since the IWGDPT published their recommendations and a few things have changed in the Internet ecosystem. The community certainly has a better understanding of the degree of government surveillance. Also, the underlying technology has evolved.

To advance the understanding of what could be done to improve VoIP security and privacy I compiled a slide deck to start the discussion about how the existing working paper could be updated, i.e., what recommendations data protection enforcement agencies could provide primarily to VoIP service providers, and equipment manufacturers.

The slide deck is a first draft and I hope to receive some feedback from the Internet community as well as from data protection authorities.

Here is a summary of the story (since the slides might not be self-explanatory).

Problem Description

First, there are problems beside government surveillance but those are currently forgotten in light of all the NSA discussions. Here are a few examples:

  1. Earlier this year security researchers have found out that links exchanged via programs like Skype had been retrieved from by Microsoft, as explained in this press article. While one can easily argue that this serves a security purpose the problem here in fact was with transparency. Most users were kept under the impression that Skype is a peer-to-peer system and uses end-to-end security so that no other party than the two end points is able to read the traffic. Obviously, that does not seem to be true and the proprietary nature of Skype makes is very difficult to find out what is happening.
  2. It is quite common to re-invent the wheel when it comes to Internet services. Of course the existing standards (like SIP, XMPP, and WebRTC) look very complicated for a newbie. So, why not develop something much simpler and better? The guys behind WhatsApp and also Cryptocat thought that this is the way to go. Well. Of course designing security into a system requires a lot of expertise and you can get it wrong very easily. Here are some blog posts that report problems with WhatsApp and Cryptocat.
  3. Of course you may also have VoIP providers who have rather relaxed security practices in general or may operate with a business model that does not provide a lot of incentives for privacy protection in general.

Note that I mix providers offering voice services with those offering other real-time communication services. I do this since there is often very little difference in terms of the actually involved protocols (although deployment-wise they may differ).


Today’s VoIP Landscape

Once the problems are understood there is the question about how various VoIP services today look like and there have been changes as well.

First, more and more application providers on the Internet establish silos in their communication architecture. The problem is that you cannot take random client software (like you can do today with an email client) and get it to work with a random VoIP provider. The RTCWeb model is a classical example but even smart phone applications follow a similar scheme. In the RTCWeb example the server provides the code (in form of JavaScript) for the browser to execute. Of course, from an innovation point of view this gives service providers much better possibilities to adapt the software to new needs. The IAB covered this trend at one technical plenary under the title “Post Standardization” (see plenary content here and an accompanying document here).

From a security and privacy point of view the challenge, however, is that a user never knows what software it is actually running. Everything may change at any time. Unless there is a lot of trust from the user in the service provider everything is lost.

A secondary effect is that many of the previously standardized protocols are not necessarily used in the way expected and hence custom designs dominate but security features are hard to get correct, as the last 20 years clearly demonstrate. For privacy protection the situation is even worse since many companies have incentives that are in conflict to users since the entire industry is looking for cloud computing, and big data analytics to discover “something new”. These industry trends do not line up nicely with basic privacy principles like data minimization and purpose limitation.

Data Routing and Interconnection

Two other aspects need to be considered, namely

  1. The involvement of interconnection providers, and
  2. The route VoIP data takes

In the early days of VoIP standardization in the IETF the idea was that interconnection would work similar to email (which lets one email provider talk directly to another email provider without any other entities in the middle). That was a good idea but the business models of operators were different. Consequently, intermediaries were introduced and, for end users, these intermediaries are invisible to a large extend. Another way to understand the role of these intermediaries is to glance at the credit card industry: Credit card companies use, in certain circumstances, the Society for Worldwide Interbank Financial Telecommunication (SWIFT) to process financial transactions. End users have not been aware of the presence of SWIFT in the transactions and even less aware of the fact that SWIFT make personal data accessible to US authorities, as this write-up of the Article 29 working party describes.

Is it too farfetched to wonder whether governments work together with interconnection providers to obtain transaction data of VoIP calls or, worse, the actual content of the communication?

It has to be pointed out that XMPP today is deployed without intermediaries, very much in the same way as email systems are deployed. It also provides a standardized way to build federated communication systems. XMPP is, however, mostly used for instant messaging and Google, who is using XMPP for Google Hangout, dropped support for server-to-server federation in May 2013 turning their services into a silo similar to the Facebook silo (who are also using XMPP). Consequently, a user who is on Facebook using XMPP cannot communicate with a user who uses Google’s XMPP services.

The route the data takes may, of course, be different than the route the signaling messages take when communication between two or more endpoints. There is even a standardized protocol to allow the best possible route to be determined, namely the Interactive Connectivity Establishment (ICE). One could also provide VPN tunnels, independent TURN servers, or even Tor as input to ICE so that the routing of the VoIP data packets remains separate.

However, in most cases the service provider has ultimately the full control of the routing of the packets and will therefore be able to see the content. As such, playing with the packet routing to obtain some level of security by itself is insufficient. Only cryptographic security mechanisms can help.

Securing Communication

There are at least two important areas in securing real-time communication protocols, namely

  1. Securing the signaling messages, and
  2. Securing the actual communication payload (voice packets, for example)

The security mechanisms look somewhat differently and a discussion about the design decisions with impact to privacy in case of SIP-based presence services can be found in RFC 6973.

For signaling traffic it is not possible to protect the entire communication end-to-end since various parts of the messages need to be understood by the different servers to ensure routing of the messages. Typically, one differentiates between client-to-server and server-to-server communication. For server-to-server communication it is assumed (on paper) that those exchanges are protected using TLS (or IPsec) but of course many deployments rather fall back to an illusion of physical security. For the client-to-server communication the story is more complicated. TLS with server-side authentication is assumed (although often not provided) but the client/user authentication typically happens via username & password layered on top of TLS.

If this type of security is indeed provided then it provides protection against eavesdroppers, who are not part of the legitimate protocol exchange. The protection is of course not provided against collecting information about the user’s communication behavior by VoIP providers and intermediaries (or even by the VoIP client software running on the end device).

An important task in end-to-end communication is to either present the calling party identity to the callee or to hide it. In the context of VoIP this identity information typically comes in form of the calling party identifier (phone number or URI) + contact information. On one hand conveying these identifiers is a privacy violation but on the other hand it provides privacy protection for the callee since he can decide based on the calling party whether he wants to get interrupted or not. Typically, many systems today use some form of whitelist (in the form of a buddy list) to filter incoming communication attempts. New users have to go through an “introduction” phase first.

Two types of approaches have been developed to communicate identity information within the signaling messages, namely:

  1. A chain of trust/non-cryptographic approach (for example, P-Asserted-Identity)
  2. A cryptographic approach (for example, SIP Identity)

Various problems surfaced with the chain of trust approach (which is also used in today’s telephone system) with caller-id spoofing and telephony denial of service attacks. The cryptographic approach is, however, also not without problems from a deployment point of view due to the nature of the intermediaries, who invalidate the cryptographic protection.

A more detailed discussion of the topic can be found here and with IETF#87 a new working group, called “Secure Telephone Identity Revised” (STIR), has been started to tackle some of the problems.

To protect the content of the communication is story is even more complicated since the goal is to securely authenticate the parties on both ends of the communication. It turns out that the solutions very much depend on who to trust and what the anticipated capabilities of the adversary are. On top of it, there are also challenges in the interworking with existing technologies (e.g., PSTN interworking).

As an example of what is meant by the assumptions consider ZRTP and DTLS-SRTP:

  • ZRTP assumes that callee/caller recognize each other’s voice (due to the voice fingerprint authentication procedure). Of course, without voice there is no voice fingerprint and there are also communication interactions where the voice of the other communication partner is not known.
  • DTLS-SRTP on the other hand assumes that SIP identity protects the fingerprints of public keys exchanged between the two parties. While SIP identity can be added by the endpoints themselves it is more realistic that they are added by the voice service provider. Consequently, the user has to select voice server provide they trust.

Of course, this is not a new area of work and a document with requirements and use cases can be found in RFC 5479.

My Recommendations

After all this background, what are the possible recommendations that can be given to VoIP providers and their equipment manufacturers.

  1. Requirement for Transparency
    1. In particular, it is important to know what information is collected by whom and for what purpose? What is the retention period?
    2. What security technology is available? How is information protected?
  2. User Participation
    1. What are the controls for users to control sharing with other users and with intermediaries? e.g., identity information
    2. Are whitelists (buddylists) available? How can the delivery of identity information to the callee be suppressed?
    3. In the Web context with many possible communication partners Is there an ability to view granted permissions and to revoke them (e.g., access to camera, microphone).
  3. Security
    1. Mandatory security for signaling traffic (client-to-server & server-to-server)
    2. Mandatory E2E security for data traffic: is it possible to mandate SRTP for all voice communication? Can something be recommended about the actual key management technique, particularly since there are various techniques available and some of them with questionable security benefits (like SDES). There will obviously be an inherit conflict between lawful intercept and the desire of end users to keep the communication content confidential.
    3. For the case where the exchanged data is not voice but rather instant messaging, or pure data the security solutions are obviously very different. What can be recommended in that case? For XMPP the e2e security mechanism (using the IETF JOSE work) is still work in progress and the S/MIME-based solution in SIP might not be deployable unless it is paired with another technology, such as SIP Cert, which provides a way to distribute the certificates. RFC 3923 provides the e2e security version using S/MIME for XMPP, which of course suffers from the same limitations as the SIP-based counterpart.
    4. Allow key exchange mechanisms to be replaced by third parties (pluggable models). This is a common concept used in other authentication protocols, like EAP, SASL or the GSS-API. It gives the communications partners the ability to adjust their capabilities to their needs.
    5. Should perfect forward secrecy be mandated to avoid future compromise of the communication content?
    6. Protection against unauthorized access of stored data.
    7. Software has to come with an update mechanism to react quickly to discovered vulnerabilities.
  4. Privacy-friendly defaults
  5. Re-use open standards that have enjoyed wide community review to ensure the quality of the used technology. (-> to increase transparency)
  6. Use open source code. This should also increase the quality and transparency.
  7. Allow users to choose their identity provider (-> to increase competition and choice)
  8. Offer federated use (-> to increase competition and choice)
  9. Enable data portability to make it easier for users to switch their provider (for example by extracting the buddy list) (-> to increase competition and choice)
  10. Preference for cryptographic identity conveyance (-> to lower misattribution & intrusion)
  11. Offer capabilities for direct exchange of data (-> to provide data minimization)

For users there is only one recommendation, namely to select the application providers operating in jurisdictions they feel comfortable with. This selection will also impact the applicable data protection laws.

Final remarks

To solicit feedback I am curious whether these recommendations are detailed enough? What else could be recommended?  What can be said about the real-time web case where the security and privacy challenges are even bigger?

Please drop me a message to hannes.tschofenig AT gmx.net, respond on this mailing list, or comment on the blog post.

Sep 13

HTTP 2.0

The IETF is working on a new version of HTTP, called HTTP 2.0, in the HTTPbis working group already for some time. The Wiki page provides a bit of additional data about the goals. The working draft of HTTP 2.0 introduces some major changes to HTTP 1.1 and the possibility to mandate the use of TLS (as the only option) was discussed some time ago but the group decided against it.

However, with the recent debate about PRISM the group has at the last meeting decided to revisit this decision. A presentation from the working group chair from the last IETF meeting in Berlin can be found here. The media has picked this item up, see for example FT article “Internet launches fightback against state snoopers“.  The decision at the meeting got a bit misinterpreted since the author of the article already anticipates the outcome of the discussion.


RTCWeb and E2E Security

The IETF has a long history in developing real-time communication protocols, such as the Session Initiation Protocol (SIP, which is also used by the 3GPP IMS), the Extensible Messaging and Presence Protocol (XMPP), and most recently the RTCWeb protocol, which builds on the Web infrastructure and JavaScript.

The work around RTCWeb has an impact to various other IETF areas but the core specifications are developed in the IETF RTCWEB group and in the W3C.  In addition to various functional aspects the chairs put an important item on the agenda for the last meeting: the group had to decide about the automated key management protocol and two proposals were put forward, namely (a) SDES and (b) DTLS-SRTP.

SDES carries keying material for e2e media security along the signaling path so that signaling intermediaries are able to see the keying material. This approach is simple to implement and convenient for those who want to provide lawful intercept functionality (or other form of inspection) of the end-to-end voice communication.

The argument in favor of SDES has been presented during the meeting by Hadriel Kaplan (Oracle) and Martin Thomson (Skype). The arguments for DTLS-SRTP have been provided by Eric Rescorla. It is worthwhile to take a look at the slide decks to see how differently technical solutions can be presented. I sometimes have to think about the movie “Thank You for Smoking“.

At the end of the meeting the participants hummed in favor of DTLS-SRTP, as the meeting minutes capture. For many IETF meeting participants this was a very important decision and various security experts decided to attend the RTCWeb face-to-face meeting, particularly in light of the PRISM discussions, to influence the decision.


TLS 1.3: The Next Generation of Transport Layer Security

A side-effect of the design of HTTP 2.0, the work on RTCWeb, and the overall attempt to make the Web (particularly for the mobile environment) is the renewed interest in the IETF TLS working group. On one hand there is a desire for more security protection and on the other hand TLS needs to become faster. Cryptographic computations and the latency of the security handshake come at a cost and therefore major Web companies, most notable Google, have been looking at ways to reduce optimize TLS.

These new developments include application layer protocol negotiation to allow de-multiplexing of HTTP 1.1 and HTTP 2.0 payloads, OCSP stapling and multiple OCSP stapling to avoid separate protocol exchanges for checking the status of certificates,,TLS channel ids to develop a sort-of cryptographic cookie at the TLS layer, and mostly recently TLS 1.3. A presentation that outlines some of the design characteristics from the TLS co-chair and TLS author, Eric Rescorla, can be found here. While Eric describes the changes as minor they constitute a major improvement compared to earlier TLS versions, such as the addition of a Diffie-Hellman exchange to avoid passive eavesdropping on the TLS exchange (which is a privacy increasing functionality).

In general, privacy concerns had come up in the TLS working group in various discussions and it appears that there is a better understanding of the need for considering privacy in the design of various TLS protocol extensions.


IAB Privacy Considerations

The IAB privacy consideration document has now been published as RFC 6973. To better inform the IETF community about the guidelines found in that document the IAB privacy program has been working on a tutorial. The IETF #87 meeting was used for a trial run with selected persons (typically working group chairs) to solicit feedback on how to better approach the wider IETF community.

A recording of the presentation is available and the slides are available for download here. The trial run resulted in lots of feedback and adjustments to the tutorial will be made. A revised tutorial for a much larger audience is planned for the upcoming IETF meeting in Vancouver (Nov. 2013).

The IETF security area directors are planning to publish a document that requires IETF document authors to address privacy in the protocols since the IAB document is currently a guidance document but the Internet Engineering Group (IESG) is in a much better position to encourage document authors to consider privacy. This approach would be similar to what was done with security and BCP 107 and BCP 61.


Tor meets the IETF

Various members of the Tor project, including Jacob Appelbaum and Linus Nordberg, decided to attend the Berlin IETF meeting to discuss the news about PRISM, to share information about their work, and to determine how cooperation with the IETF community could look like.

In addition to side meetings, a presentation at the Security Area Advisory Group was given and a new mailing list, perpass@ietf.org, was created to continue the discussions.

The interaction with the Tor community will provide the IETF with additional insight on how to prevent fingerprinting and to learn about the state of middleboxes throughout networks (as part of the Tor project work on the Open Observatory of Network Interference). The Tor community on the other hand will benefit from additional reviews and involvement of the IETF community in the ongoing developments.


Security Incident Information Sharing

High-profile data breaches and security incidents on the Internet are gaining increasing attention from the Internet community, but also from the public and from governments. Various CyberSecurity activities have recently been launched, such as the EU CyberSecurity strategy, the EC created Network and Information Security Platform, and the NIST CyberSecurity framework. Sharing of security incident information is one of the items that is supposed to improve awareness and shall ensure a quicker response to security incidents.

Since the IETF has standardization efforts ongoing in the area of incident and abuse information sharing a workshop was held prior to the IETF #87 meeting. The workshop page also contains slides from the presenters, including presentations about privacy and legal aspects. The workshop report is still work in progress.

While there are many challenges it became clear that the privacy related aspects are not well understood. For example, what information about the communication interactions is allowed to be collected? What information can be shared with third parties and under what conditions? While various techniques have been deployed for a long time already (such as in the case of spam filtering) it is was not obvious from the discussions at the workshop how well they have been analyzed against the data protection frameworks. Further discussions will be certainly needed and recommendations will have to be developed as more sharing is expected in the near future, also due to recently created work in the IETF such as Security Automation and Continuous Monitoring (SACM).


Improving the Web Public Key Infrastructure (WebPKI)

The problems with the WebPKI have received the attention by the Internet security community when DigiNotar, a Dutch certificate authority, had a security breach and in the same year a Comodo affiliate was compromised. Both cases lead to fraudulent issue of certificates and raise questions regarding the strength of the PKI used by many applications today.

A compromise of the PKI obviously leads to privacy violations since it allows an attacker to intercept encrypted communication.

Almost two years have passed since these incidents happened. Although new technical mechanisms have been developed within the IETF, such as DANEkey pinning, and certificate transparency, very little has happened in terms of actual deployment. Consequently, the attacks that have happened two years ago may happen any time again.

With the NIST workshop on “Improving Trust in the Online Marketspace” various stakeholders were invited to discuss the technical options for improving the state-of-the-art. It became clear that there are very few organizations who have the desired properties, such as technical expertise, appropriate membership model, and independence, to lead the follow-up discussions.

As a follow-up activity the Internet Architecture Board will work together with the Internet Society to initiate work on a roadmap and shared vision on how to proceed on this topic. A meeting is planned at the upcoming IETF meeting and a workshop will be organized early next year.

May 13

Those who have followed the work in the European Emergency Number Association (EENA) know that we have been trying to initiate interoperability testing events for some time now. Testing implementations of the next generation protocols developed by various major standardization organizations (e.g., IETF, 3GPP, IEEE, OMA, NENA, ETSI, and EENA) will help us to detect bugs in open source libraries and commercial software, to foster information exchange between equipment vendors and infrastructure providers along the entire emergency services value chain, to reveal gaps in protocol specifications, and will also help the wider eco-system to gain more confidence in the reliability, security, and stability of the next generation emergency services system. Ultimately, we all will benefit from a working emergency services infrastructure.

Organizing interoperability events does, however, require resources for preparing the test specifications, for arranging the face-to-face interop events itself (e.g., cost for renting rooms and network infrastructure, travel support for participants), for marketing and outreach, and for conveying results back to various organizations.

To provide a platform for these interoperability testing events we need your help: with your support we would like to convince the European Commission to consider supporting the call for such a testing program.

Download the EENA support letter or view it here:

Please indicate your support via this website or by sending a mail to Hannes Tschofenig ht@eena.org and/or to Jerome Paris jp@eena.org.

Your support is crucial: if you support such a testing programme, could you please respond at latest by Tuesday, June 4th indicating “I support this paper”.




Hannes Tschofenig's Recent Tweets