Monthly Archives: October 2017

Privacy and Trustworthiness for Web Notifications

Mailboxes with flags

HTTPS (HTTP over TLS) is possibly the most widely used security protocol in existence. HTTPS is a two-party protocol; it involves a single client and a single server. This aspect of the protocol limits the ways in which it can be used.

The recently published RFC 8188 provides protocol designers a new option for building multi-party protocols with HTTPS by defining a standardized format for encrypting HTTP message bodies. While this tool is less capable than other encryption formats, like CMS (RFC 5652) or JOSE (RFC 7516), it is designed for simplicity and ease-of-integration with existing HTTP semantics.

The WebPush protocol (RFC 8030) provides an example of the how the encrypted HTTP content coding could be used.

In WebPush, there are three parties: a user agent (in most cases this is a Web browser), an application server, and a push service. The push service is an HTTP server that has a special relationship with the user agent. The push service can wake a user agent from sleep and contact it even though it might be behind a firewall or NAT.

The application server uses the push service to send a push message to a user agent. The push service receives a message from the application server, and then forwards the contents of the push message to the user agent at the next opportunity. It is important here to recognize that the push service only forwards messages. It has no need to see or modify push messages. Both the user agent and the application server only communicate via the push service, but they both want some assurance that the push service cannot read or modify push messages. Nor do they want the push service to be able to create false push messages.

For example, an alerting service might use WebPush to deliver alerts to mobile devices without increased battery drain. Push message encryption ensures that these messages are trustworthy and allows the messages to contain confidential information.

The document draft-ietf-webpush-encryption, which was recently approved for publication as an RFC, describes how push messages can be encrypted using RFC 8188. The encrypted content coding ensures that the push service has access to the information it needs, such as URLs and HTTP header fields, but that the content of push messages is protected.

WebPush is available in some web browsers through the W3C Push API, which requires push message encryption.

Martin Thomson

ENAME Workshop

The IAB held a workshop on Explicit Internet Naming Systems last week in Vancouver, B.C., and there are a couple of interesting early conclusions to draw. The first conclusion is actually about the form of the workshop, which was an experiment by the IAB. While many of our workshops run like mini conferences, with paper presentations and follow-on questions, this workshop was structured as a retreat. There was a relatively small number of participants gathered around a common table space, with sessions organized as joint discussions around specific topics. Moderators kept the conversations on topic, and discussants kept it moving forward if it lagged.

The result was one of the most interactive workshops I’ve attended. While we did have to run a queue in most sessions (and the queues could get a bit long), the conversations had real give-and-take, more like an IETF hallway discussion than a series of mic line comments.
While I don’t expect that this style would be appropriate for all our workshops, it’s useful to know that this retreat style can work. I suspect we would use it again in other situations where the IAB is trying to step back from the current framing of an issue and synthesize a set of new approaches.

A second early conclusion is that the IAB was right in suspecting that its previous framing of the issues around Internet naming and internationalization wasn’t quite right. Among other things, that framing had us trying to push human interface considerations up the stack and away from the protocol mechanics that worked on what we saw as identifiers. One clear conclusion from this workshop was that the choice of identifier structure and protocol mechanics will constrain the set of possible human interfaces. When those constraints don’t match the needs of the human users, the resulting friction generates a lot of heat (and not much light). One suggestion for follow on work from the workshop will be to document the user interface considerations that arise from using different types of identifiers, so that new systems can recognize more easily the consequences of the identifier types they choose.

An additional point that came up multiple times was the role of implicit context in transforming references in speech or writing into identifiers that drive specific protocol mechanics. While the shorthand for this is “the side of the bus” problem, the space is much larger and includes heuristic search systems ranging from the educated guess through to highly personalized algorithmic responses. The participants saw a couple of possible ways in which standards developed in this area might advance how these tuples of context elements and references can be safely used to mint or manage identifiers. A first step in that will be to suggest that the IAB look at language tags, network provider identifiers, and similar common representations of context to see how they function across protocols. Follow on work from that might include developing common vocabularies, serialization formats, and analyzing privacy implications.

Like many others, I came away from the workshop with the realization that there is a dauntingly large amount of work to be done in this space. The workshop participants are drafting more than a half dozen follow-on recommendations for the IAB, as well as describing a potential research group and producing some individual drafts. Despite the amount of work facing us, I and many other participants left the room more hopeful that we came in, both that we can make progress and that some of the tools we need are already available.

If you’d like to join in the conversation, you can share your comments on Internet naming by email to or directly with the IAB at

New work at IETF 100

Before each IETF meeting, the Internet Engineering Steering Group (IESG) collects proposals for Birds of a Feather (BOF) sessions. These sessions are designed to help determine whether new working groups should be formed or to generate discussion about a topic within the IETF community. We decide which ones are ready for community discussion on the IETF meeting agenda, with input from the Internet Architecture Board (IAB). We did this last week in preparation for IETF 100 and I wanted to report the conclusions:

Software Updates for Internet of Things (SUIT) will be having a working-group-forming BOF session at IETF 100. The SUIT work is focused on developing a modern interoperable approach for securely updating the software in Internet of Things (IoT) devices. Security experts, researchers, and regulators recommend that all IoT devices be equipped with a secure firmware update mechanism, but current approaches are largely proprietary. The SUIT BOF will discuss an architecture for IoT firmware updates and a manifest format for describing meta-data about firmware images. The SUIT mailing list is here.

Trusted Execution Environment Provisioning (TEEP) will be reconvening for a second BOF after an initial session at IETF 98 and a tutorial at IETF 99. The goal of TEEP is to standardize protocol(s) for provisioning applications into secure areas now supported on some computer processors, known as Trusted Execution Environments (TEEs). TEEs are currently found in home routers, set-top boxes, smart phones, tablets and wearables. Most of these systems use proprietary application layer protocols. TEEP aims to produce an interoperable application-layer security protocol that enables the configuration of security credentials and software running in a TEE. The TEEP mailing list is here.

Data Center Routing (DCROUTING) will be having a non-working-group-forming BOF. Over the last year, there have been discussions in a number of routing area working groups about proposals aimed at routing within a data center. Because of their topologies (traditional and emerging), traffic patterns, need for fast restoration, and need for low human intervention, among other things, data centers are driving a set of routing solutions specific to them. The intent of this BOF is to discuss the special circumstances that surround routing in the data center and potential new solutions. The objective is not to select a single solution, but to determine whether there is interest and energy in the community to work on any of the proposals. The mailing list is here.

IETF Administrative Support Activity 2.0 (IASA 2.0) will be having a non-working-group-forming BOF to continue discussions that have been taking place over the last year regarding refactoring the IETF Administrative Support Activity (IASA). The IASA 2.0 design team has been incorporating feedback from IETF 99 and further refining and expanding their documentation of the problem, requirements, and solution options. The goal of this session will be to determine the sense of the community about the direction for IASA 2.0. The mailing list is here.

We also received a proposal for a WG-forming BOF concerning Common Operation and Management on Network Slicing (COMS), focused on standardizing an information model to support network slicing in 5G. While the scope of this work has narrowed considerably since IETF 99 based on feedback received there, the new proposal was not approved for this meeting cycle. Further work is needed. The Operations and Management (OPS) area directors and interested IAB members will continue working with the proponents prior to IETF 100. The Operations and Management Area Working Group (OPSAWG) may serve as a venue for related discussions if that work bears fruit.

Finally, we’ll have two newly chartered working groups meeting for the first time at IETF 100: Email mailstore and eXtensions To Revise or Amend (EXTRA) and DNS over HTTPS (DOH). EXTRA is chartered to work on updates, extensions, and revisions to the email-related protocols IMAP, Sieve, and ManageSieve. DOH will be standardizing encodings for DNS queries and responses that are suitable for use in HTTPS, enabling the domain name system to function over certain paths where existing DNS methods experience problems. The mailing lists are here: extra, doh. A third new working group, IDentity Enabled Networks (IDEAS), was proposed but not chartered due to a number of concerns expressed during IETF community review of the charter.

Together with the rest of the IETF’s ongoing work, it will be exciting to see all of the new efforts kick off in Singapore.

Alissa Cooper
IETF Chair