Idea to encrypt Web traffic at rest hits the IETF’s Standard Track

In spite of the rise of HTTPS, there are still spots where content originating on the Web can remain unencrypted, so a Mozilla engineer wants to close one of those gaps.

In an Internet Engineering Task Force RFC published this month, a proposal by Martin Thomson (also a member of the Internet Architecture Board), first mooted in late 2015, has been updated and pushed into the IETF’s Standard Track.

In RFC 8188, Thomson explains that there’s a good reason to encrypt HTTP message payloads even when HTTPS isn’t in play: TLS (the basis of HTTPS) only encrypts a channel between client and server.

If, for example, you want to store content on a server without exposing it to the server, or replicate it between servers, some other encryption is required. Rather than hoping that engineers remember that, Thomson hopes to embed it in applications with a standard specifying content coding for HTTP.

He also notes that it wasn’t practical to adapt message-based encryption formats (he cites OpenPGP’s RFC 4880, the Cryptographic Message Syntax in RFC 5652 and other examples) because those don’t meet HTTP’s need for stream processing.

Rather, Thomson’s RFC suggests using AES 128 in Galois/Counter Mode.

The scheme “only provides content-origin” authentication, the RFC notes, but that “ensures that an entity with access to the content-encryption key produced the encrypted data.”


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s