I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is part 6 of the HTTP/1.1 and covers the caching in http. The security considerations section is quite short covering the case that caches are attractive targets for attackers and that the fact that cache can reveal information long after the information has been removed from the network. I think the security considerations section should list other attacks too. Things that comes to my mind: - Cache poisoning attacks, i.e. attacker who can control the www-server for a moment could pre-load cache with stuff that will stay there for long time (as long as the cache control attributes say). This includes negative result (404) caching. - Cache caching stuff that was not supposed to be cached, like authentication credentials in forms of cookies (the RFC6265 - "HTTP State Management Mechanism" says that the presense of the cookies does not preclude HTTP caches from storing and reusing a response). This can be problem unless all applications using cookies actually make sure that they set all pages as non-cacheable. - Cache might leak out information to other users of the cache who fetched the page in the first time. This leaking can happen in multiple ways (for example cookies, etc). Actually just timing can tell that someone has already fetched the page to the cache, which in some cases might be enough to leak information out. There most likely are still other attacks which I did not list above. Also as cookies are quite often used in various things like authentication, session identifiers, language selection etc, I think the section 3 should mention something about them, especially mention that RFC6265 says they can be cached (this was suprise for me, I would have expected cookies to be counted in the same category as authorization fields i.e. fields thta disable caching). I was also suprised not to find warning about the caching of the cookies in the RFC6265, but perhaps we should add note here in security considerations section saying that by default cookies are cachable, so applications using them must make sure they are not cached unless wanted so. It might not be able to reach its intended users (the ones writing web applications), but at least it might spread the information to some relevant parties. In summary I think this document needs bit more work in security considerations section. -- kivinen at iki.fi