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

Tero Kivinen <kivinen@iki.fi> Tue, 18 September 2012 08:53 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440B121F878B for <secdir@ietfa.amsl.com>; Tue, 18 Sep 2012 01:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.556
X-Spam-Level:
X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYLUHCcNpuYQ for <secdir@ietfa.amsl.com>; Tue, 18 Sep 2012 01:53:49 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 50C9A21F876A for <secdir@ietf.org>; Tue, 18 Sep 2012 01:53:48 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id q8I8rje4002453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Sep 2012 11:53:45 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q8I8riPw016336; Tue, 18 Sep 2012 11:53:44 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <20568.13975.955380.415363@fireball.kivinen.iki.fi>
Date: Tue, 18 Sep 2012 11:53:43 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <F7064610-7F37-4F4A-A288-1B4A99681590@mnot.net>
References: <20550.1861.349381.646147@fireball.kivinen.iki.fi> <BEF0DC8E-4E9B-446D-9B0D-93F61E5F828B@mnot.net> <F7064610-7F37-4F4A-A288-1B4A99681590@mnot.net>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 16 min
X-Total-Time: 6 min
Cc: draft-ietf-httpbis-p6-cache.all@tools.ietf.org, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-httpbis-p6-cache-20
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Sep 2012 08:53:50 -0000

Mark Nottingham writes:
> Please see:
>   https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#security.considerations
> On 05/09/2012, at 12:11 PM, Mark Nottingham <mnot@mnot.net> wrote:
> > On 04/09/2012, at 11:51 PM, Tero Kivinen <kivinen@iki.fi> wrote:
> >> 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.

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.

> >> - 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.

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.

> >> - 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.

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? 
-- 
kivinen@iki.fi