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

Mark Nottingham <mnot@mnot.net> Wed, 05 September 2012 02:11 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 803F321F84B9; Tue, 4 Sep 2012 19:11:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.599
X-Spam-Level:
X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 TiZS4NHdqWAp; Tue, 4 Sep 2012 19:11:46 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id BDE5921E80AC; Tue, 4 Sep 2012 19:11:45 -0700 (PDT)
Received: from mnot-mini.mnot.net (unknown [118.209.13.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C11F322E1F4; Tue, 4 Sep 2012 22:11:34 -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: <20550.1861.349381.646147@fireball.kivinen.iki.fi>
Date: Wed, 5 Sep 2012 12:11:31 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <BEF0DC8E-4E9B-446D-9B0D-93F61E5F828B@mnot.net>
References: <20550.1861.349381.646147@fireball.kivinen.iki.fi>
To: Tero Kivinen <kivinen@iki.fi>
X-Mailer: Apple Mail (2.1486)
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, draft-ietf-httpbis-p6-cache.all@tools.ietf.org, iesg@ietf.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: Wed, 05 Sep 2012 02:11:47 -0000

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,


On 04/09/2012, at 11:51 PM, Tero Kivinen <kivinen@iki.fi> wrote:

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

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