Google LLC

pmeenan@google.com

Shopify Inc.

yoav.weiss@shopify.com

ART HTTP compression dictionary shared brotli zstandard dictionary delta compression This document specifies a mechanism for dictionary-based compression in the Hypertext Transfer Protocol (HTTP). By utilizing this technique, clients and servers can reduce the size of transmitted data, leading to improved performance and reduced bandwidth consumption. This document extends existing HTTP compression methods and provides guidelines for the delivery and use of compression dictionaries within the HTTP protocol.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
  • .  Use Cases
    • .  Version Upgrade
    • .  Common Content
  • .  Notational Conventions
• .  Dictionary Negotiation
  • .  Use-As-Dictionary
    • .  "match"
    • .  "match-dest"
    • .  "id"
    • .  "type"
    • .  Examples
  • .  Available-Dictionary
    • .  Dictionary Freshness Requirement
    • .  Dictionary URL Matching
    • .  Multiple Matching Dictionaries
  • .  Dictionary-ID
• .  The "compression-dictionary" Link Relation Type
• .  Dictionary-Compressed Brotli
• .  Dictionary-Compressed Zstandard
• .  Negotiating the Content Encoding
  • .  Accept-Encoding
  • .  Content-Encoding
• .  IANA Considerations
  • .  Content Encoding Registration
  • .  Header Field Registration
  • .  Link Relation Registration
• .  Compatibility Considerations
• .  Security Considerations
  • .  Changing Content
  • .  Reading Content
  • .  Security Mitigations
    • .  Cross-Origin Protection
    • .  Response Readability
    • .  Server Responsibility
• . Privacy Considerations
• . References
  • .  Normative References
  • .  Informative References
• Authors' Addresses

Introduction This specification defines a mechanism for using designated HTTP responses as an external dictionary for future HTTP responses for compression schemes that support using external dictionaries (e.g., Brotli and Zstandard ). This document describes the HTTP headers used for negotiating dictionary usage and registers content-encoding values for compressing with Brotli and Zstandard using a negotiated dictionary. The negotiation of dictionary usage leverages HTTP's content negotiation (see ) and is usable with all versions of HTTP.

Use Cases Any HTTP response can be specified for use as a compression dictionary for future HTTP requests, which provides a lot of flexibility. Two common use cases that are seen frequently are described below.

Version Upgrade Using a previous version of a resource as a dictionary for a newer version enables delivery of a delta-compressed version of the changes, usually resulting in significantly smaller responses than what can be achieved by compression alone. For example:

Version Upgrade Example Client Server | | | GET /app.v1.js | |------------------------------------------------->| | | | 200 OK | | Use-As-Dictionary: match="/app*js" | | <full app.v1.js resource - 100KB compressed> | |<-------------------------------------------------| | | Some time later ... Client Server | | | GET /app.v2.js | | Available-Dictionary: :pZGm1A...2a2fFG4=: | | Accept-Encoding: gzip, br, zstd, dcb, dcz | |------------------------------------------------->| | | | 200 OK | | Content-Encoding: dcb | | <delta-compressed app.v2.js resource - 1KB> | |<-------------------------------------------------| | |

Common Content If several resources share common patterns in their responses, then it can be useful to reference an external dictionary that contains those common patterns, effectively compressing them out of the responses. Some examples of this are common template HTML for similar pages across a site and common keys and values in API calls. For example:

Common Content Example Client Server | | | GET /index.html | |--------------------------------------------------->| | | | 200 OK | | Link: <.../dict>; rel="compression-dictionary" | | <full index.html resource - 100KB compressed> | |<---------------------------------------------------| | | | GET /dict | |--------------------------------------------------->| | | | 200 OK | | Use-As-Dictionary: match="/*html" | |<---------------------------------------------------| | | Some time later ... Client Server | | | GET /page2.html | | Available-Dictionary: :pZGm1A...2a2fFG4=: | | Accept-Encoding: gzip, br, zstd, dcb, dcz | |--------------------------------------------------->| | | | 200 OK | | Content-Encoding: dcb | | <delta-compressed page2.html resource - 10KB> | |<---------------------------------------------------| | |

Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the following terminology from to specify syntax and parsing: Dictionary, String, Inner List, Token, and Byte Sequence. This document uses the line folding strategies described in . This document also uses terminology from and .

Dictionary Negotiation

Use-As-Dictionary When responding to an HTTP Request, a server can advertise that the response can be used as a dictionary for future requests for URLs that match the rules specified in the "Use-As-Dictionary" response header. The "Use-As-Dictionary" response header is a Structured Field Dictionary with values for "match", "match-dest", "id", and "type".

"match" The "match" value of the "Use-As-Dictionary" response header is a String value that provides the URL Pattern to use for request matching (see ). The URL Pattern used for matching does not support using regular expressions. The following algorithm is used to validate that a given String value is a valid URL Pattern that does not use regular expressions and is for the same Origin () as the dictionary. It will return TRUE for a valid match pattern and FALSE for an invalid pattern that MUST NOT be used.

1. Let MATCH be the value of "match" for the given dictionary.
2. Let URL be the URL of the dictionary request.
3. Let PATTERN be a "URL pattern struct" created by running the steps to "create a URL pattern" by setting input=MATCH and baseURL=URL (see ).
4. If the result of running the "has regexp groups" steps for PATTERN returns TRUE, then return FALSE (see the last list in ).
5. Return TRUE.

The "match" value is required and MUST be included in the "Use-As-Dictionary" response header for the dictionary to be considered valid. Operating at the HTTP level, the specified match patterns will operate on the percent-encoded version of the URL path (see ). For example, the URL "http://www.example.com/düsseldorf" would be encoded as "http://www.example.com/d%C3%BCsseldorf" and a relevant match pattern would be: Use-As-Dictionary: match="/d%C3%BCsseldorf"

"match-dest" The "match-dest" value of the "Use-As-Dictionary" response header is an Inner List of String values that provides a list of Fetch request destinations for the dictionary to match (see "RequestDestination" in ). An empty list for "match-dest" MUST match all destinations. For clients that do not support request destinations, the client MUST treat it as an empty list and match all destinations. The "match-dest" value is optional and defaults to an empty list.

"id" The "id" value of the "Use-As-Dictionary" response header is a String value that specifies a server identifier for the dictionary. If an "id" value is present and has a string length longer than zero, then it MUST be sent to the server in a "Dictionary-ID" request header when the client sends an "Available-Dictionary" request header for the same dictionary (see ). The server identifier MUST be treated as an opaque string by the client. The server identifier MUST NOT be relied upon by the server to guarantee the contents of the dictionary. The dictionary hash MUST be validated before use. The "id" value string length (after any decoding) supports up to 1024 characters. The "id" value is optional and defaults to the empty string.

"type" The "type" value of the "Use-As-Dictionary" response header is a Token value that describes the file format of the supplied dictionary. "raw" is defined as a dictionary format that represents an unformatted blob of bytes suitable for any compression scheme to use. If a client receives a dictionary with a type that it does not understand, it MUST NOT use the dictionary. The "type" value is optional and defaults to "raw".

Examples

Path Prefix A response that contained a response header (as shown below) would specify matching any document request for a URL with a path prefix of /product/ on the same Origin () as the original request: NOTE: '\' line wrapping per RFC 8792 Use-As-Dictionary: \ match="/product/*", match-dest=("document")

Versioned Directories A response that contained a response header (as shown below) would match any path that starts with "/app/" and ends with "/main.js": Use-As-Dictionary: match="/app/*/main.js"

Available-Dictionary When an HTTP client makes a request for a resource for which it has an appropriate dictionary, it can add an "Available-Dictionary" request header to the request to indicate to the server that it has a dictionary available to use for compression. The "Available-Dictionary" request header is a Structured Field Byte Sequence containing the SHA-256 hash of the contents of a single available dictionary. The client MUST only send a single "Available-Dictionary" request header with a single hash value for the best available match that it has available. For example: Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:

Dictionary Freshness Requirement To be considered as a match, the dictionary resource MUST be either fresh or allowed to be served stale (see ).

Dictionary URL Matching When a dictionary is stored as a result of a "Use-As-Dictionary" directive, it includes a "match" string and an optional "match-dest" string that are used to match an outgoing request from a client to the available dictionaries. To see if an outbound request matches a given dictionary, the following algorithm will return TRUE for a successful match and FALSE for no-match:

1. If the current client supports request destinations and a "match-dest" string was provided with the dictionary:
   • Let DEST be the value of "match-dest" for the given dictionary.
   • Let REQUEST_DEST be the value of the destination for the current request.
   • If DEST is not an empty list and if REQUEST_DEST is not in the DEST list of destinations, return FALSE.
2. Let BASEURL be the URL of the dictionary request.
3. Let URL represent the URL of the outbound request being checked.
4. If the Origin of BASEURL and the Origin of URL are not the same, return FALSE (see ).
5. Let MATCH be the value of "match" for the given dictionary.
6. Let PATTERN be a "URL pattern struct" created by running the steps to "create a URL pattern" by setting input=MATCH and baseURL=URL (see ).
7. Return the result of running the "match" steps on PATTERN with input=URL, which will check for a match between the request URL and the supplied "match" string (see "Match" in ).

Multiple Matching Dictionaries When there are multiple dictionaries that match a given request URL, the client MUST pick a single dictionary using the following rules:

1. For clients that support request destinations, a dictionary that specifies and matches a "match-dest" takes precedence over a match that does not use a destination.
2. Given equivalent destination precedence, the dictionary with the longest "match" takes precedence.
3. Given equivalent destination and match length precedence, the most recently fetched dictionary takes precedence.

Dictionary-ID When an HTTP client makes a request for a resource for which it has an appropriate dictionary and the dictionary was stored with a server-provided "id" in the "Use-As-Dictionary" response header, the client MUST echo the stored "id" in a "Dictionary-ID" request header. The "Dictionary-ID" request header is a Structured Field String of up to 1024 characters (after any decoding) and MUST be identical to the server-provided "id". For example, given an HTTP response that set a dictionary ID: Use-As-Dictionary: match="/app/*/main.js", id="dictionary-12345" A future request that matches the given dictionary will include both the hash and the ID: Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=: Dictionary-ID: "dictionary-12345"

The "compression-dictionary" Link Relation Type This specification defines the "compression-dictionary" link relation type that provides a mechanism for an HTTP response to provide a URL for a compression dictionary that is related to but not directly used by the current HTTP response. The "compression-dictionary" link relation type indicates that fetching and caching the specified resource is likely to be beneficial for future requests. The response to some of those future requests likely have the ability to use the indicated resource as a compression dictionary. Clients can fetch the provided resource at a time that they determine would be appropriate. The response to the fetch for the compression dictionary needs to include a "Use-As-Dictionary" response header and a caching response header for it to be usable as a compression dictionary. The link relation only provides the mechanism for triggering the fetch of the dictionary. The following example shows a link to a resource at https://example.org/dict.dat that is expected to produce a compression dictionary: Link: <https://example.org/dict.dat>; rel="compression-dictionary"

Dictionary-Compressed Brotli The "dcb" content encoding identifies a resource that is a "Dictionary-Compressed Brotli" stream. A "Dictionary-Compressed Brotli" stream has a fixed header that is followed by a Shared Brotli stream. The header consists of a fixed 4-byte sequence and a 32-byte hash of the external dictionary that was used. The Shared Brotli stream is created using the referenced external dictionary and a compression window that is at most 16 MB in size. The dictionary used for the "dcb" content encoding is a "raw" dictionary type as defined in and is treated as a prefix dictionary as defined in . The 36-byte fixed header is as follows:

Magic_Number:

4 fixed bytes -- 0xff, 0x44, 0x43, 0x42.

SHA_256_Hash:

32 bytes. SHA-256 hash digest of the dictionary .

Clients that announce support for dcb content encoding MUST be able to decompress resources that were compressed with a window size of up to 16 MB. With Brotli compression, the full dictionary is available during compression and decompression independent of the compression window, allowing for delta-compression of resources larger than the compression window.

Dictionary-Compressed Zstandard The "dcz" content encoding identifies a resource that is a "Dictionary-Compressed Zstandard" stream. A "Dictionary-Compressed Zstandard" stream is a binary stream that starts with a 40-byte fixed header and is followed by a Zstandard stream of the response that has been compressed with an external dictionary. The dictionary used for the "dcz" content encoding is a "raw" dictionary type as defined in and is treated as a raw dictionary as per . The 40-byte header consists of a fixed 8-byte sequence followed by the 32-byte SHA-256 hash of the external dictionary that was used to compress the resource:

Magic_Number:

8 fixed bytes -- 0x5e, 0x2a, 0x4d, 0x18, 0x20, 0x00, 0x00, 0x00.

SHA_256_Hash:

32 bytes. SHA-256 hash digest of the dictionary .

The 40-byte header is a Zstandard skippable frame (little-endian 0x184D2A5E) with a 32-byte length (little-endian 0x00000020) that is compatible with existing Zstandard decoders. Clients that announce support for dcz content encoding MUST be able to decompress resources that were compressed with a window size of at least 8 MB or 1.25 times the size of the dictionary, whichever is greater, up to a maximum of 128 MB. The window size used will be encoded in the content (currently, this can be expressed in powers of two only) and it MUST be lower than this limit. An implementation MAY treat a window size that exceeds the limit as a decoding error. With Zstandard compression, the full dictionary is available during compression and decompression until the size of the input exceeds the compression window. Beyond that point, the dictionary becomes unavailable. Using a compression window that is 1.25 times the size of the dictionary allows for full delta compression of resources that have grown by 25% between releases while still giving the client control over the memory it will need to allocate for a given response.

Negotiating the Content Encoding When a compression dictionary is available to compress the response to a given request, the encoding to be used is negotiated through the regular mechanism for negotiating content encoding in HTTP through the "Accept-Encoding" request header and "Content-Encoding" response header. The dictionary to use is negotiated separately and advertised in the "Available-Dictionary" request header.

Accept-Encoding When a dictionary is available for use on a given request and the client chooses to make dictionary-based content encoding available, the client adds the dictionary-aware content encodings that it supports to the "Accept-Encoding" request header. For example: Accept-Encoding: gzip, deflate, br, zstd, dcb, dcz When a client does not have a stored dictionary that matches the request or chooses not to use one for the request, the client MUST NOT send its dictionary-aware content encodings in the "Accept-Encoding" request header.

Content-Encoding If a server supports one of the dictionary encodings advertised by the client and chooses to compress the content of the response using the dictionary that the client has advertised, then it sets the "Content-Encoding" response header to the appropriate value for the algorithm selected. For example: Content-Encoding: dcb If the response is cacheable, it MUST include a "Vary" header to prevent caches from serving dictionary-compressed resources to clients that don't support them or serving the response compressed with the wrong dictionary. For example: Vary: accept-encoding, available-dictionary

IANA Considerations

Content Encoding Registration IANA has added the following entries to the "HTTP Content Coding Registry" maintained at :

Name:

dcb

Description:

"Dictionary-Compressed Brotli" data format.

Reference:

RFC 9842,

Name:

dcz

Description:

"Dictionary-Compressed Zstandard" data format.

Reference:

RFC 9842,

Header Field Registration IANA has added the following entries to the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at :

Field Name	Status	Reference
Use-As-Dictionary	permanent	RFC 9842,
Available-Dictionary	permanent	RFC 9842,
Dictionary-ID	permanent	RFC 9842,

Link Relation Registration IANA has added the following entry to the "Link Relation Types" registry maintained at :

Relation Name:

compression-dictionary

Description:

Refers to a compression dictionary used for content encoding.

Reference:

RFC 9842,

Compatibility Considerations It is not unusual for devices to be on the network path that intercept, inspect, and process HTTP requests (web proxies, firewalls, intrusion detection systems, etc.). To minimize the risk of these devices incorrectly processing dictionary-compressed responses, compression dictionary transport MUST only be used in secure contexts (HTTPS).

Security Considerations The security considerations for Brotli , Shared Brotli , and Zstandard apply to the dictionary-based versions of the respective algorithms.

Changing Content The dictionary must be treated with the same security precautions as the content because a change to the dictionary can result in a change to the decompressed content. The dictionary is validated using an SHA-256 hash of the content to make sure that the client and server are both using the same dictionary. The strength of the SHA-256 hash algorithm isn't explicitly needed to counter attacks since the dictionary is being served from the same origin as the content. That said, if a weakness is discovered in SHA-256 and it is determined that the dictionary negotiation should use a different hash algorithm, the "Use-As-Dictionary" response header can be extended to specify a different algorithm and the server would just ignore any "Available-Dictionary" requests that do not use the updated hash.

Reading Content The compression attacks in show that it's a bad idea to compress data from mixed (e.g., public and private) sources. The data sources include not only the compressed data but also the dictionaries. For example, if secret cookies are compressed using a public-data-only dictionary, information about the cookies is still leaked. The dictionary can reveal information about the compressed data and vice versa. That is, data compressed with the dictionary can reveal contents of the dictionary when an adversary can control parts of the data to compress and see the compressed size. On the other hand, if the adversary can control the dictionary, the adversary can learn information about the compressed data.

Security Mitigations If any of the mitigations do not pass, the client MUST drop the response and return an error.

Cross-Origin Protection To make sure that a dictionary can only impact content from the same origin where the dictionary was served, the URL Pattern used for matching a dictionary to requests () is guaranteed to be for the same origin that the dictionary is served from.

Response Readability For clients, like web browsers, that provide additional protection against the readability of the payload of a response and against user tracking, additional protections MUST be taken to make sure that the use of dictionary-based compression does not reveal information that would not otherwise be available. In these cases, dictionary compression MUST only be used when both the dictionary and the compressed response are fully readable by the client. In browser terms, that means either the dictionary and compressed response are same-origin to the context they are being fetched from or the response is cross-origin and passes the Cross-Origin Resource Sharing (CORS) check (see ).

Server Responsibility As with any usage of compressed content in a secure context, a potential timing attack exists if the attacker can control any part of the dictionary or if it can read the dictionary and control any part of the content being compressed while performing multiple requests that vary the dictionary or injected content. Under such an attack, the changing size or processing time of the response reveals information about the content, which might be sufficient to read the supposedly secure response. In general, a server can mitigate such attacks by preventing variations per request, as in preventing active use of multiple dictionaries for the same content, disabling compression when any portion of the content comes from uncontrolled sources, and securing access and control over the dictionary content in the same way as the response content. In addition, the following requirements on a server are intended to disable dictionary-aware compression when the client provides CORS request header fields that indicate a cross-origin request context. The following algorithm will return FALSE for cross-origin requests where precautions such as not using dictionary-based compression should be considered:

1. If there is no "Sec-Fetch-Site" request header, return TRUE.
2. If the value of the "Sec-Fetch-Site" request header is "same-origin", return TRUE.
3. If there is no "Sec-Fetch-Mode" request header, return TRUE.
4. If the value of the "Sec-Fetch-Mode" request header is "navigate" or "same-origin", return TRUE.
5. If the value of the "Sec-Fetch-Mode" request header is "cors":
   • If the response does not include an "Access-Control-Allow-Origin" response header, return FALSE.
   • If the request does not include an "Origin" request header, return FALSE.
   • If the value of the "Access-Control-Allow-Origin" response header is "*", return TRUE.
   • If the value of the "Access-Control-Allow-Origin" response header matches the value of the "Origin" request header, return TRUE.
6. Return FALSE.

Privacy Considerations Since dictionaries are advertised in future requests using the hash of the content of the dictionary, it is possible to abuse the dictionary to turn it into a tracking cookie. To mitigate any additional tracking concerns, clients MUST treat dictionaries in the same way that they treat cookies . This includes partitioning the storage using partitioning similar to or stricter than the partitioning used for cookies, as well as clearing the dictionaries whenever cookies are cleared.

References Normative References WHATWG WHATWG Living Standard Commit snapshot: This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Federal Information Processing Standard, FIPS Google, Inc. Google, Inc. Google, Inc. Google, Inc. Google, Inc. This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields. This document obsoletes RFC 8941. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] WHATWG WHATWG Living Standard Commit snapshot: This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types"). It also defines the serialisation of such links in HTTP headers with the Link header field. Zstandard, or "zstd" (pronounced "zee standard"), is a lossless data compression mechanism. This document describes the mechanism and registers a media type, content encoding, and a structured syntax suffix to be used when transporting zstd-compressed content via MIME. Despite use of the word "standard" as part of Zstandard, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only. This document replaces and obsoletes RFC 8478. Informative References This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches. This document is not an Internet Standards Track specification; it is published for informational purposes. This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK] Over the last few years, there have been several serious attacks on Transport Layer Security (TLS), including attacks on its most commonly used ciphers and modes of operation. This document summarizes these attacks, with the goal of motivating generic and protocol-specific recommendations on the usage of TLS and Datagram TLS (DTLS). This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods.

Authors' Addresses Google LLC

pmeenan@google.com

Shopify Inc.

yoav.weiss@shopify.com