Subject: [secdir] Secdir review of draft-ietf-httpbis-p6-cache-20

From: Tero Kivinen <[email-masked]>
Date: Tue, 4 Sep 2012 16:51:01 +0300

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.
-- 
[email-masked]

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 5 Sep 2012 12:11:31 +1000

Hi Tero,

CC:ing the HTTP mailing list.

These all seem reasonable. I'll work to update the Security Considerations and publish in -21, will ping you once that happens.

Thanks,

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

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 5 Sep 2012 13:53:13 +1000

[ removing the IESG from the CC list]

Please see:
  https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#security.considerations

Cheers,

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 18 Sep 2012 11:53:43 +0300

> >> say). This includes negative result (404) caching.

The current text for this seems to be ok (from the work in progress
draft):

	Implementation flaws might allow attackers to insert content
	into a cache ("cache poisoning"), leading to compromise of
	clients that trust that content. Because of their nature,
	these attacks are difficult to mitigate.

> >> make sure that they set all pages as non-cacheable.

Same for this:

	Likewise, implementation flaws (as well as misunderstanding of
	cache operation) might lead to caching of sensitive
	information (e.g., authentication credentials) that is thought
	to be private, exposing it to unauthorised parties.

	Note that the Set-Cookie response header [RFC6265] does not
	inhibit caching; a cacheable response with a Set-Cookie header
	can be (and often is) used to satisfy subsequent requests to
	caches. Servers who wish to control caching of these responses
	are encouraged to emit appropriate Cache-Control response
	headers.

> >> in some cases might be enough to leak information out.

This was not added to security considerations at all. Was this
intentional, or just left out by accident? Was there something unclear
about this attack? 
-- 
[email-masked]

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 18 Sep 2012 13:19:16 -0700

> intentional, or just left out by accident? Was there something unclear

I didn't see how it was materially different than the previous one (unintentional caching of sensitive information). Could you explain how it is?

Regards,

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