Re: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-httpbis-header-compression-10

Jari Arkko <> Thu, 22 January 2015 13:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 30E011ACC85; Thu, 22 Jan 2015 05:00:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kX_cJEtazFAN; Thu, 22 Jan 2015 05:00:13 -0800 (PST)
Received: from ( [IPv6:2a00:1d50:2::130]) by (Postfix) with ESMTP id B86271ACC92; Thu, 22 Jan 2015 05:00:12 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10C5A2CCC0; Thu, 22 Jan 2015 15:00:06 +0200 (EET) (envelope-from
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mXJAaMyJZ8jF; Thu, 22 Jan 2015 15:00:05 +0200 (EET)
Received: from [] ( [IPv6:2a00:1d50:2::130]) by (Postfix) with ESMTP id 378E02CC5F; Thu, 22 Jan 2015 15:00:04 +0200 (EET) (envelope-from
Content-Type: multipart/signed; boundary="Apple-Mail=_44A44A32-4890-4596-BD83-3CD2DB88DA55"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Jari Arkko <>
In-Reply-To: <>
Date: Thu, 22 Jan 2015 14:22:20 +0200
Message-Id: <>
References: <>, <> <> <>
To: "Black, David" <>, Martin Thomson <>, RUELLAN Herve <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
Cc: "" <>, "General Area Review Team \(\)" <>, "" <>, "" <>
Subject: Re: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-httpbis-header-compression-10
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Jan 2015 13:00:18 -0000

Thanks for the in-depth review, David. Much appreciated, as always, 
and particularly so with this important draft.

With regards to the fixed design:

>> A few people objected to this on the grounds that this flies in the
>> face of a body of accepted wisdom on extensibility in protocols.  But
>> that flexibility turns out to be contrary to the aforementioned goals.
>> Ultimately, this choice was very clearly and consistently the
>> consensus of the working group.

>   The HPACK format is intentionally simple and inflexible.  Both
>   characteristics reduce the risk of interoperability or security
>   issues based by implementation error.  No extensibility mechanisms
>   are defined; changes to the format are only possible by defining a
>   complete replacement.

I agree.

For the rest, I’m skipping to the main remaining debated point:

>>> That list doesn't exist, because the need to avoid indexing is highly
>>> contextual.  Like padding, I don't expect this feature to be widely
>>> used, because it requires specific knowledge, but it is necessary to
>>> avoid low-entropy secrets from being exposed to CRIME-like attacks.
> Designing a mechanism to resist an attack but failing to provide guidance
> (either here or in the main HTTP v2 draft) on how to use it to resist that
> attack does not solve the actual problem, no matter how clever the
> mechanism.
> I hope the Security ADs notice this discussion, because the current
> situation looks like a security flaw from here (likely to result
> in insecure implementations, even though the implementations contain
> the mechanism needed to fix the security problem).
> If a list of specific fields is not reasonable, some specific guidance on
> where and why this mechanism needs to be applied is in order, as (IMHO)
> it is unreasonable to expect the entire global implementer community
> to have a detailed working command of the CRIME attack and its HPACK
> implications wrt specific pieces of information exchanged in the HTTP v2
> protocol.

I am sympathetic to David’s point here, although it is not necessarily clear
to me that such information needs to be a part of this specific draft; it could
be defined elsewhere as well.

For what it is worth, I’m doing a review of this document along with Gen-ART
review comments, and I think where I have ended up is that the above issue
is a Comment from my perspective (and not a blocking Discuss).

But I’d like to hear some feedback on this point though, or has that
discussion already happened in the WG in the past? Also, for my
education, are the standardised header fields that would clearly end 
up on the list, if it existed, or is this only for other
or future header fields?