Re: [secdir] Secdir review of draft-ietf-httpbis-p6-cache-20
Mark Nottingham <mnot@mnot.net> Tue, 18 September 2012 20:19 UTC
Return-Path: <mnot@mnot.net>
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 23ECD21E8042 for <secdir@ietfa.amsl.com>; Tue, 18 Sep 2012 13:19:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 SuTo4F6bW2mV for <secdir@ietfa.amsl.com>; Tue, 18 Sep 2012 13:19:30 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF1B21E8040 for <secdir@ietf.org>; Tue, 18 Sep 2012 13:19:30 -0700 (PDT)
Received: from [172.30.66.198] (unknown [72.247.151.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D916F22E25C; Tue, 18 Sep 2012 16:19:17 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <20568.13975.955380.415363@fireball.kivinen.iki.fi>
Date: Tue, 18 Sep 2012 13:19:16 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <5968E08E-1A55-440E-9A3C-1477A5832C50@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> <20568.13975.955380.415363@fireball.kivinen.iki.fi>
To: Tero Kivinen <kivinen@iki.fi>
X-Mailer: Apple Mail (2.1486)
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 20:19:31 -0000
On 18/09/2012, at 1:53 AM, Tero Kivinen <kivinen@iki.fi> wrote: > 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? 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/
- [secdir] Secdir review of draft-ietf-httpbis-p6-c… Tero Kivinen
- Re: [secdir] Secdir review of draft-ietf-httpbis-… Mark Nottingham
- Re: [secdir] Secdir review of draft-ietf-httpbis-… Mark Nottingham
- Re: [secdir] Secdir review of draft-ietf-httpbis-… Tero Kivinen
- Re: [secdir] Secdir review of draft-ietf-httpbis-… Mark Nottingham
- [secdir] SecDir review of draft-ietf-radext-ipv6-… Yoav Nir
- Re: [secdir] SecDir review of draft-ietf-radext-i… Benoit Claise
- Re: [secdir] SecDir review of draft-ietf-radext-i… Wojciech Dec (wdec)