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

Matthew Lepinski <mlepinski.ietf@gmail.com> Mon, 19 January 2015 03:46 UTC

MIME-Version: 1.0
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
Precedence: list

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