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

Matthew Lepinski <mlepinski.ietf@gmail.com> Mon, 26 January 2015 21:06 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 6D2691AD1DB; Mon, 26 Jan 2015 13:06:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 iw4l-lE9tNPJ; Mon, 26 Jan 2015 13:05:59 -0800 (PST)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DB7E1A1B20; Mon, 26 Jan 2015 13:05:32 -0800 (PST)
Received: by mail-oi0-f51.google.com with SMTP id x69so9256013oia.10; Mon, 26 Jan 2015 13:05:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Nr23dQODn7tQO6ZOzUM9U8T7sNrXRHZcWQO9rjdIu6w=; b=uDl3VEuevkp0zBm1KrVgC6B7LPII9HZumKEQNrBl7w6tSwxvY3JGDwJaY9/I0chFwU m8p6Ru8tbsfg1MpbevNeX4ieR4KJf02Yk5DHXgApKH5TDltMuLLc6Uu4Ewkjj/aYyCnX Ift6FlYQyFWIoBVmGSzpJmRg1dGwSvKy4jLgt4BEpRWcV4k1x/fZcobJvil7hgZhbvjQ iWKbZ6zhrQa0x6X9bjkXZyHO2M+TQuektafO3rAKl6G8RSw5MSyg38By2lSnpViW8iOc rY+4QdSsManasvAS09iU7nYRDeAkGcMC5K8yPGharKuW0nxlvVVJZqrgnUsjg3zASFsc W9XA==
MIME-Version: 1.0
X-Received: by 10.182.27.241 with SMTP id w17mr13817351obg.14.1422306330814; Mon, 26 Jan 2015 13:05:30 -0800 (PST)
Received: by 10.202.135.17 with HTTP; Mon, 26 Jan 2015 13:05:30 -0800 (PST)
In-Reply-To: <54C67136.8090908@crf.canon.fr>
References: <CANTg3aBf00Q8MyjwQk9P1+NLkJdgHZafLLPP7CAQ5tWsPtAeow@mail.gmail.com> <54C67136.8090908@crf.canon.fr>
Date: Mon, 26 Jan 2015 16:05:30 -0500
Message-ID: <CANTg3aDEXuB=3CB13hAdLyp0MgfqJVXhsnV+i4RvZ5p2_HHTYw@mail.gmail.com>
From: Matthew Lepinski <mlepinski.ietf@gmail.com>
To: =?UTF-8?Q?Herv=C3=A9_Ruellan?= <herve.ruellan@crf.canon.fr>
Content-Type: multipart/alternative; boundary=001a113345c69c2d27050d947fb9
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/ampRndmltv4TqZd7X8WPGneYen0>
Cc: draft-ietf-httpbis-header-compression.all@tools.ietf.org, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
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 21:06:02 -0000

Thanks a lot.

706 looks good. It is a small change, but I think it will be helpful.

On Mon, Jan 26, 2015 at 11:54 AM, Hervé Ruellan <herve.ruellan@crf.canon.fr>;
wrote:

> 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é.
>