Skip to main content

  • Pre-IETF 110 technical update

    With the IETF 110 meeting beginning next week, this post provides an update on the steps that have been taken since IETF 109 to improve the technical services that support participation in IETF online meetings.

    • Jay DaleyIETF Executive Director
    2 Mar 2022

  • Applied Network Research Prize presentations at IETF 110

    A pair of presentations featured during the Internet Research Task Force (IRTF) Open session of the IETF 110 Online meeting (8-12 March 2021) will highlight the application of machine learning to video bit-rate adaptation and Domain Name System (DNS) caching and privacy.

    • Colin PerkinsIRTF Chair
    4 Mar 2021

  • Revised IETF sponsorship program

    After review, research, and consultation with existing meeting hosts and sponsors, the IETF Administration LLC is implementing a restructured sponsorship program in support of the Internet Engineering Task Force (IETF), Internet Research Task Force (IRTF), and Internet Architecture Board (IAB).

    • Jay DaleyIETF Executive Director
    2 Mar 2021

  • Handling IESG ballot positions

    This document is written to help authors and chairs (especially newer authors and chairs) understand what to do with IESG ballot positions. The most important bit of advice is “Don’t Panic.”

    • Warren KumariOperations and Management Area Director
    • Internet Engineering Steering Group
    26 Feb 2021

  • IETF LLC 2020 End Of Year Survey

    The IETF Administration LLC ran a survey over December 2020 - January 2021 to assess community satisfaction with the LLC’s performance in 2020 and community views on our proposed activities for 2021.

    • Jason LivingoodIETF Administration LLC Board Chair
    22 Feb 2021
  • Show all

Filter by topic and date

Filter by topic and date

Privacy and Trustworthiness for Web Notifications

  • Martin ThomsonIETF Participant

18 Oct 2017

RFC 8188 builds on existing protocols to provide a new option for delivering trustworthy messages containing confidential information over the Internet.

Mailboxes with flags

HTTPS (HTTP over TLS) is possibly the mostwidely 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.

Share this page