Conditional Request Security Considerations

[mnot@…]

[ from the secdir review]

Security Considerations (section 6)

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.

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.

• - 2.1, p5, weak vs strong, 4th paragraph

"A cryptographic hash function", which one? I think you need to state at least that you should choose one that is collusion resistant (and this should probably go into the security considerations)

• - 2.3.1 p 9, generation

same discussion as in 2.1 about collission resistant hashes

[fielding@…]

From [1801]:

Add a paragraph about validators to security section and refer to collision-resistant hash instead of cryptographic hash. Addresses #365