#365: Conditional Request Security Considerations

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/365>:

> To start with the Security Considerations (section 6), there aren't
> any..... or rather, section 6 refers to the security considerations of
> part 1 and states that the security considerations are the same as for
> HTTP in general. IMO that is a bit too easy, for example throughout
> the text there is discussion about clock synchronization, evaluation
> of weak conditionals, hashes etc. All of those can lead to the client
> having a "wrong" view of the resource. I would expect some discussion
> as to what that could mean and what measures could be taken to avoid that.

Perhaps. However, when used for validation, the worst case scenario is that validation will fail, leading to transfer of more bytes. I.e., an optimisation will fail, but the protocol will still operate "correctly."

In the case of a preconditional request - e.g., If-Match on a PUT - again, the request may fail, but the result will be conservative; i.e., the operation will not succeed. The only case that's interesting from a security standpoint, I think, is if an attacker modifies ETags (for example) in such a way that a request that would have failed succeeds, thereby "losing" an update by another author. 

However, I do think that this is covered by the security considerations in general; i.e., if you're operating HTTP in the clear, people can do all sorts of things to your messages.

> Also, in part 1, security considerations 8.5 there is some discussion
> about MitM attacks and evil proxies, and the general statement is made
> that proxies should not be trusted anymore than the person who
> operates it. Whereas it is true that everyone in the path can change
> the transmitted information at will, I could imagine that with ETags
> one could actually implement some rsort of integrity protection by
> using ETags that are signed hashes of the content that is
> transfered.... thinking out loud... anyway, my bottom line is that I
> am not sure that the security properties of the system as a whole
> don't change by introducing conditionals.

ETags are absolutely not used for integrity protection; they are only an identifier for a particular message; hashes are mentioned as one way to generate that identifier, but they're vehemently opaque to the consumer.

Does this satisfy your concerns? If so, we'll close the issue. If not, perhaps you could suggest some text?

Regards,




--
Mark Nottingham
http://www.mnot.net/

Received on Monday, 16 July 2012 06:19:42 UTC