[secdir] Secdir review of draft-ietf-httpbis-p6-cache-20
Tero Kivinen <kivinen@iki.fi> Tue, 04 September 2012 13:51 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 C942321F850C; Tue, 4 Sep 2012 06:51:09 -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 7+wj77S308VC; Tue, 4 Sep 2012 06:51:09 -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 A10B021F84F8; Tue, 4 Sep 2012 06:51:08 -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 q84Dp23r010825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2012 16:51:02 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q84Dp1X8010549; Tue, 4 Sep 2012 16:51:01 +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: <20550.1861.349381.646147@fireball.kivinen.iki.fi>
Date: Tue, 04 Sep 2012 16:51:01 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-httpbis-p6-cache.all@tools.ietf.org
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 53 min
X-Total-Time: 50 min
Subject: [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, 04 Sep 2012 13:51:09 -0000
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
- [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)