6. Security Considerations

6.1. HTTP Messages Are Not Protected in Full

This document specifies a data integrity mechanism that protects HTTP representation data or content, but not HTTP header and trailer fields, from certain kinds of corruption.

Integrity fields are not intended to be a general protection against malicious tampering with HTTP messages. In the absence of additional security mechanisms, an on-path malicious actor can either remove a digest value entirely or substitute it with a new digest value computed over manipulated representation data or content. This attack can be mitigated by combining mechanisms described in this document with other approaches such as Transport Layer Security (TLS) or digital signatures (for example, HTTP Message Signatures [SIGNATURES]).

6.2. End-to-End Integrity

Integrity fields can help detect representation data or content modification due to implementation errors, undesired "transforming proxies" (see Section 7.7 of [HTTP]), or other actions as the data passes across multiple hops or system boundaries. Even a simple mechanism for end-to-end representation data integrity is valuable because a user agent can validate that resource retrieval succeeded before handing off to an HTML parser, video player, etc., for parsing.

Note that using these mechanisms alone does not provide end-to-end integrity of HTTP messages over multiple hops since metadata could be manipulated at any stage. Methods to protect metadata are discussed in Section 6.3.

6.3. Usage in Signatures

Digital signatures are widely used together with checksums to provide the certain identification of the origin of a message [FIPS186-5]. Such signatures can protect one or more HTTP fields and there are additional considerations when Integrity fields are included in this set.

There are no restrictions placed on the type or format of digital signature that Integrity fields can be used with. One possible approach is to combine them with HTTP Message Signatures [SIGNATURES].

Digests explicitly depend on the "representation metadata" (e.g., the values of Content-Type, Content-Encoding, etc.). A signature that protects Integrity fields but not other "representation metadata" can expose the communication to tampering. For example, an actor could manipulate the Content-Type field-value and cause a digest validation failure at the recipient, preventing the application from accessing the representation. Such an attack consumes the resources of both endpoints. See also Section 3.2.

Signatures are likely to be deemed an adversarial setting when applying Integrity fields; see Section 5. Repr-Digest offers an interesting possibility when combined with signatures. In the scenario where there is no content to send, the digest of an empty string can be included in the message and, if signed, can help the recipient detect if content was added either as a result of accident or purposeful manipulation. The opposite scenario is also supported; including an Integrity field for content and signing it can help a recipient detect where the content was removed.

Any mangling of Integrity fields might affect signature validation. Examples of such mangling include de-duplicating digests or combining different field values (see Section 5.2 of [HTTP]).

6.4. Usage in Trailer Fields

Before sending Integrity fields in a trailer section, the sender should consider that intermediaries are explicitly allowed to drop any trailer (see Section 6.5.2 of [HTTP]).

When Integrity fields are used in a trailer section, the field-values are received after the content. Eager processing of content before the trailer section prevents digest validation, possibly leading to processing of invalid data.

One of the benefits of using Integrity fields in a trailer section is that it allows hashing of bytes as they are sent. However, it is possible to design a hashing algorithm that requires processing of content in such a way that would negate these benefits. For example, Merkle Integrity Content Encoding [MICE] requires content to be processed in reverse order. This means the complete data needs to be available, which means there is negligible processing difference in sending an Integrity field in a header versus a trailer section.

6.5. Variations within Content-Encoding

Content coding mechanisms can support different encoding parameters, meaning that the same input content can produce different outputs. For example, GZIP supports multiple compression levels. Such encoding parameters are generally not communicated as representation metadata. For instance, different compression levels would all use the same "Content-Encoding: gzip" field. Other examples include where encoding relies on nonces or timestamps, such as the aes128gcm content coding defined in [RFC8188].

Since it is possible for there to be variation within content coding, the checksum conveyed by the Integrity fields cannot be used to provide a proof of integrity "at rest" unless the whole content is persisted.

6.6. Algorithm Agility

The security properties of hashing algorithms are not fixed. Algorithm agility (see [RFC7696]) is achieved by providing implementations with flexibility to choose hashing algorithms from the IANA Hash Algorithms for HTTP Digest Fields registry; see Section 7.2.

Transition from weak algorithms is supported by negotiation of hashing algorithm using Want-Content-Digest or Want-Repr-Digest (see Section 4) or by sending multiple digests from which the receiver chooses. A receiver that depends on a digest for security will be vulnerable to attacks on the weakest algorithm it is willing to accept. Endpoints are advised that sending multiple values consumes resources that may be wasted if the receiver ignores them (see Section 3).

While algorithm agility allows the migration to stronger algorithms, it does not prevent the use of weaker algorithms. Integrity fields do not provide any mitigations for downgrade or substitution attacks (see Section 1 of [RFC6211]) of the hashing algorithm. To protect against such attacks, endpoints could restrict their set of supported algorithms to stronger ones and protect the fields' values by using TLS and/or digital signatures.

6.7. Resource Exhaustion

Integrity field validation consumes computational resources. In order to avoid resource exhaustion, implementations can restrict validation of the algorithm types, the number of validations, or the size of content. In these cases, skipping validation entirely or ignoring validation failure of a more-preferred algorithm leaves the possibility of a downgrade attack (see Section 6.6).