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 RFC8188 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 (RFC5652) or JOSE (RFC7516), it is designed for simplicity and ease-of-integration with existing HTTP semantics.
The WebPush protocol (RFC8030) provides an example of 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 Network Address Translation.
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 RFC8188. 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.
Original post appeared on the IETF Blog.
Martin Thomson is an engineer at Mozilla.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.