Code change:
includes security considerations from
NAME probably those considerations are redundant: implementers know that computing digest has a cost. Do you think it's worth spending more time to land this PR or we can close it?
I'd go with a simpler statement such as or say nothing.
NAME this PR contains your proposal.
A threat model for . is this useful/required? should this go into Security Considerations or in another document?
User User-Agent: see RFC7230 Intermediaries that do not do TLS termination Intermediaries that do TLS termination.Application: the application actually running the service Intermediaries can alter HTTP messages Intermediaries that do transport-layer termination can alter HTTP messages The application can erroneously or purposedly alter the message User can forge messages with the same checksum values An intermediary can alter an HTTP header by chance or purpose. [x] Use an end-to-end transport-layer security mechanism. A TLS-terminator intermediary can alter representation-metadata by chance or purpose. [x] Use a signature mechanism that covers both and the representation-metadata. A TLS-terminator intermediary can replace the representation-data with another one having the same digest-algorithm. A malicious User can forge two messages with: different representation-data same Digest header values send an HTTP message with the first representation-data then pretend he sent the one with the second representation-data. A malicious Server could implement a similar behavior. [x] Use a digest-algorithm that is not subject to collision (eg. sha-256), or refuse to use digest-algorithms subject to collision. A User could exhaust server resources by chance or purpose via: 1- sending a huge representation 2- digest calculation of the complete representation 3- forcing the server to evaluate the digest of the included representation [x] To consume huge representation-data, you may consider mechanisms sending progressive integrity checksums in the payload body and just use to provide the last checksum value. A malicious User could exhaust server resources via: 1- reconstruction of the complete representation 2- digest calculation of the complete representation 3- forcing the server to evaluate many different digest-algorithms for a given representation If you are exposed to this kind of attack because reconstructing complete representations of your objects is computationally intensive, avoid using [ ] Digest with mechanisms like Range-Requests and PATCH. If you support multiple digest-algorithms: [ ] limit the supported digest-algorithms to the ones you really care for; [ ] establish a policy for validating only the digest using the stronger digest-algorithm. The recipient may skip Digest header validation by chance or purpose and still be compliant to the specification: as explained in {#digest-header} the recipient MAY ignore any or all the received representation-data-digests. This is because Digest was originally conceived in RFC3230 as a tool for the recipient to validate the received representation, but not for the sender to receive an integrity proof of the communication. [ ] You should not rely on the recipient having correctly verified the Digest value of the selected representation. If you want the recipient to validate the : [ ] agree on processing with your peer, like it is done in
Let's see if we can incorporate some of this into the security considerations.
all considerations should be inside the I-D once is merged
Thank, this works for me. Let's merge and we can iterate later if anyone thinks of something to add.

Related discussion:
text: checksum comparison and, based on the intersection of those results, conditionally pass or fail digest validation. <ins> 12.10. "Digest" validation consumes computational resources.  In order to avoid resource exhaustion, implementations can restrict validation of the algorithm types, number of validations, or the size of content. </ins> 13. 13.1.