Re: [secdir] SECDIR Review of draft-ietf-httpbis-header-compression-10

Hervé Ruellan <herve.ruellan@crf.canon.fr> Mon, 26 January 2015 16:54 UTC

Return-Path: <Herve.Ruellan@crf.canon.fr>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEF81ACCDE; Mon, 26 Jan 2015 08:54:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.26
X-Spam-Level:
X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSjeimofCWim; Mon, 26 Jan 2015 08:54:19 -0800 (PST)
Received: from inari-msr.crf.canon.fr (inari-msr.crf.canon.fr [194.2.158.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA6F1ACCE4; Mon, 26 Jan 2015 08:54:18 -0800 (PST)
Received: from mir-bsr.corp.crf.canon.fr (mir-bsr.corp.crf.canon.fr [172.19.77.99]) by inari-msr.crf.canon.fr (8.13.8/8.13.8) with ESMTP id t0QGsG6s028686; Mon, 26 Jan 2015 17:54:16 +0100
Received: from Antiope.crf.canon.fr (antiope.fesl2.crf.canon.fr [172.19.70.56]) by mir-bsr.corp.crf.canon.fr (8.13.8/8.13.8) with ESMTP id t0QGsGA7017638; Mon, 26 Jan 2015 17:54:16 +0100
Received: from timor.intra-usr.crf.canon.fr (172.20.3.149) by Antiope.crf.canon.fr (172.19.70.56) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 26 Jan 2015 17:54:14 +0100
Message-ID: <54C67136.8090908@crf.canon.fr>
Date: Mon, 26 Jan 2015 17:54:14 +0100
From: Hervé Ruellan <herve.ruellan@crf.canon.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Matthew Lepinski <mlepinski.ietf@gmail.com>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-httpbis-header-compression.all@tools.ietf.org
References: <CANTg3aBf00Q8MyjwQk9P1+NLkJdgHZafLLPP7CAQ5tWsPtAeow@mail.gmail.com>
In-Reply-To: <CANTg3aBf00Q8MyjwQk9P1+NLkJdgHZafLLPP7CAQ5tWsPtAeow@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [172.20.3.149]
X-ClientProxiedBy: Antiope.crf.canon.fr (172.19.70.56) To Antiope.crf.canon.fr (172.19.70.56)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/rb0F7PC6mCt8dM1M_S7XQ50vLTA>
X-Mailman-Approved-At: Tue, 27 Jan 2015 08:18:40 -0800
Subject: Re: [secdir] SECDIR Review of draft-ietf-httpbis-header-compression-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 26 Jan 2015 16:54:21 -0000

Hi Matthew,

On 01/19/2015 04:46 AM, Matthew Lepinski 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 with the intent of improving security
> requirements and considerations in IETF drafts.  Comments not addressed
> in last call may be included in AD reviews during the IESG review.
> Document editors and WG chairs should treat these comments just like any
> other last call comments.
>
> This document specifies HPACK, the compression scheme used by HTTP/2. A
> new compression scheme was needed for HTTP/2 because of attacks against
> systems where traditional compression schemes were used to compress HTTP
> headers sent over an encrypted TLS connection. (e.g., the CRIME attack
> against SPDY.) HPACK is specifically designed to avoid CRIME and similar
> attacks.
>
> I believe that this document is mature and nearly ready for publication.
> However, I have one concern and would request a change to the document
> (see below).
>
> After reviewing this document and looking at the PETAL paper it
> references, I am satisfied that -- as the authors claim -- the HPACK
> scheme [when used to compress HTTP headers] is secure relative to our
> (the security community) current understanding of attacks against
> encryption of compressed data. That is, I believe that the authors have
> adequately addressed -- in the design of HPACK and the associated
> Security Considerations section -- all known security issues.
>
> That being said, since HPACK is a relatively new algorithm, and since
> encryption of compressed headers is known to be somewhat perilous, it is
> possible that a clever attacker will develop a new attack in the future
> (i.e., CRIME++ ) that works against HPACK-compressed header fields. I
> haven't read the latest version of HTTP/2 carefully enough to know
> whether HTTP/2 has a mechanism for an implementation to turn off use of
> HPACK if such an attack is discovered. However, planning for a possible
> future attack against HPACK would probably be wise.

While it's not possible to turn off use of HPACK from HTTP/2, it is 
possible to not use any indexing into HPACK resulting in encoding all 
values as literals. This is the fallback if ever HPACK is compromised.

> ==========================
> REQUEST FOR CHANGE TO: draft-ietf-httpbis-header-compression
>
> The Security Considerations in this document are extremely well-written
> (particularly Sections 7.1.1 and 7.1.2). Based on experience with the
> CRIME attack, there are significant security concerns (described in
> Section 7.1) with encrypting compressed headers. Section 7.1.1 explains
> how these concerns relate to HPACK and Section 7.1.2 describes steps
> that an HPACK encoder implementation can take to mitigate these
> concerns. These sections are very important -- indeed, more important
> than the security considerations sections for many IETF documents.
>
> I would very much like to see a forward reference to Section 7.1.2 (or
> perhaps just Section 7.1 as whole) at some point earlier in the document
>   when the authors are describing the encoder (probably somewhere in
> Section 2). That is, there are important mitigation techniques that an
> implementer should have in mind when creating an HPACK encoder. I
> believe that referencing these techniques when the encoding process is
> described would be a good idea.

I added pointers to the security sections in:
https://github.com/http2/http2-spec/pull/706

> ==========================

Hervé.