search

martinthomson / http-mice

A progressive integrity content encoding for HTTP
3 stars 2 forks source link

Inconsistency in suggestions for failed validation #10

Open jyasskin opened 6 years ago

jyasskin commented 6 years ago

https://tools.ietf.org/html/draft-thomson-http-mice-02#section-2.2 says

If an integrity check fails, the message SHOULD be discarded and the exchange treated as an error unless explicitly configured otherwise. For clients, treat this as equivalent to a server error; servers SHOULD generate a 400 or other 4xx status code. However, if the integrity proof for the first record is not known, this check SHOULD NOT fail unless explicitly configured to do so.

If implementations follow the SHOULDs, an attacker can drop the initial integrity proof and change the initial record (and its size!) with impunity, but then hit a hard error if they change any subsequent record. I think https://tools.ietf.org/html/draft-thomson-postel-was-wrong-03 argues that receivers should treat a missing initial proof as a hard error too.

Sorry if I'm missing a previous discussion that gave a solid use case for this leniency.

martinthomson commented 6 years ago

So the first two don't need SHOULD, it's really not a normative thing. The last one will depend on expectations - if an endpoint expects an integrity check, then it will fail, otherwise, it's just another content encoding to remove.