Early Review of draft-ietf-httpbis-p6-cache-
review-ietf-httpbis-p6-cache-secdir-early-kivinen-2012-09-05-00

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