[secdir] SECDIR Review of draft-ietf-httpbis-header-compression-10
Matthew Lepinski <mlepinski.ietf@gmail.com> Mon, 19 January 2015 03:46 UTC
Return-Path: <mlepinski.ietf@gmail.com>
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 16F521AD0A7; Sun, 18 Jan 2015 19:46:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 QK80x_zHLX4L; Sun, 18 Jan 2015 19:46:34 -0800 (PST)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E784B1AD0A5; Sun, 18 Jan 2015 19:46:33 -0800 (PST)
Received: by mail-oi0-f41.google.com with SMTP id i138so25042387oig.0; Sun, 18 Jan 2015 19:46:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YSwuhXnOJj3jISkiMIHLlrrkW5XRJOBKndY5nYYY7Xc=; b=sEjHeBYMn+kHNkNkFwO+Nc/mr8AlMOLs5UFP7LHQZ3FtTrwxuxrCfBwy2cxQU0oAjL a30585pn0CFp1tDlHujEMCK12531fzexIz+wTQHII6DRbPrwRdvteqOjqJb94PlhcnWF SBVa9kSQZVZHW2wGuDQbjZajmjiHy89iqW7pqZ1sHM/pHi5zX0VuPQTDbqBFEM2/+2ek WIjD26/+MFLiYXT6PvZvZIIPIGB0V/IJ3GXdC8Lpvh+2doPJjSA5SwjX1RxJR9inKxcE 7xKX5gtqIeH2tyM2dNaqRmV5CSJTuCm4J3dy3gZJs/dwXesF0de+veXz3Qfe/R6Inm84 vEHw==
MIME-Version: 1.0
X-Received: by 10.60.141.103 with SMTP id rn7mr16991212oeb.73.1421639193174; Sun, 18 Jan 2015 19:46:33 -0800 (PST)
Received: by 10.202.135.17 with HTTP; Sun, 18 Jan 2015 19:46:33 -0800 (PST)
Date: Sun, 18 Jan 2015 22:46:33 -0500
Message-ID: <CANTg3aBf00Q8MyjwQk9P1+NLkJdgHZafLLPP7CAQ5tWsPtAeow@mail.gmail.com>
From: Matthew Lepinski <mlepinski.ietf@gmail.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-httpbis-header-compression.all@tools.ietf.org
Content-Type: multipart/alternative; boundary="047d7b2e7a4c1ba93c050cf92b10"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/e3Jpk5X-lvNMB0xtIJa_8d_AzYQ>
Subject: [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, 19 Jan 2015 03:46:36 -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 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. ========================== 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. ==========================
- [secdir] SECDIR Review of draft-ietf-httpbis-head… Matthew Lepinski
- Re: [secdir] SECDIR Review of draft-ietf-httpbis-… Matthew Lepinski
- Re: [secdir] SECDIR Review of draft-ietf-httpbis-… Hervé Ruellan