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: Hervé 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é. >
- [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