Header compression integrity

Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> Sun, 28 July 2013 03:59 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9B0CA11E8160 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 27 Jul 2013 20:59:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tk1Rp-Yji9+1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 27 Jul 2013 20:59:33 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org []) by ietfa.amsl.com (Postfix) with ESMTP id 4512311E8155 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 27 Jul 2013 20:59:33 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1V3I6x-0005Zy-LC for ietf-http-wg-dist@listhub.w3.org; Sun, 28 Jul 2013 03:57:35 +0000
Resent-Date: Sun, 28 Jul 2013 03:57:35 +0000
Resent-Message-Id: <E1V3I6x-0005Zy-LC@frink.w3.org>
Received: from maggie.w3.org ([]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <tatsuhiro.t@gmail.com>) id 1V3I6h-0005Z4-OO for ietf-http-wg@listhub.w3.org; Sun, 28 Jul 2013 03:57:19 +0000
Received: from mail-ob0-f171.google.com ([]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <tatsuhiro.t@gmail.com>) id 1V3I6h-0001fL-87 for ietf-http-wg@w3.org; Sun, 28 Jul 2013 03:57:19 +0000
Received: by mail-ob0-f171.google.com with SMTP id tb18so7030703obb.2 for <ietf-http-wg@w3.org>; Sat, 27 Jul 2013 20:56:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=ptSnLtWX8t5gFfymv/Sb5Uv47WdGlncP2XuZiS/DiAM=; b=T9CiAEEJNcOdg0EPME36h9txBMrdoaZU4pWYEFNufmx1Q89ySl4ZqRrqtwkpNKmAD6 eOVLklbAwcajEV8PFl8abY9Vg/zWBguyopaCejrm9AoZPXN8xSq2JJLH6qGC2IToN6y+ ypuPK4UhFj6urJurIBPJBKXgk5OgJ7C31VQ23i+gDa0Py+MsbAjwsoNw2mI2618YtLUu u/H0O1hUSK2N41qlQs+4YO2Vq5Tyg95DME7rN7/yC+0IIM+F6iMAo2ctGLFOIhGXAHZM prfXXr4ZpeGdaswuUodTGucXCuV0wWBTQ7QYa8qzXfXDU4RatWjRR2BXeC2Klaxx9/We 6f+Q==
X-Received: by with SMTP id d13mr496816igz.41.1374983813115; Sat, 27 Jul 2013 20:56:53 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 27 Jul 2013 20:56:32 -0700 (PDT)
From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Sun, 28 Jul 2013 12:56:32 +0900
Message-ID: <CAPyZ6=K8a=LqVZPq28Kmc=aoPjU4FSX+p2t_B8itFLHuBUerQQ@mail.gmail.com>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="089e0122aac2c0b62004e28a5dec"
Received-SPF: pass client-ip=; envelope-from=tatsuhiro.t@gmail.com; helo=mail-ob0-f171.google.com
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-2.641, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1V3I6h-0001fL-87 af6e00c2d130f6eda5069580df3ad63e
X-Original-To: ietf-http-wg@w3.org
Subject: Header compression integrity
Archived-At: <http://www.w3.org/mid/CAPyZ6=K8a=LqVZPq28Kmc=aoPjU4FSX+p2t_B8itFLHuBUerQQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18934
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Under the current header compression scheme, the receiver has no way to
check that the received header set is what the sender intended to transmit.
I think it would be good to add some kind of integrity checking against
uncompressed header sets(e.g., parity, hash, etc).

This problem does not occur if both ends correctly implement header
compression. But there are several corner cases (index shadowing, etc) and
its implementation complexity is certainly higher than current HTTP/1.1 and
SPDY, it may go wrong easier than before.

For example, if client encodes index badly (off-by-one error, for example),
the server may see the wrong index. The thing is this might not be
noticeable in one request/response. It might be apparent after several
requests, possibly after eviction occurs. This problem is more serious for
proxy. If proxy coalesces streams for requests to different origin servers
just like what secure SPDY proxy does, misinterpreting headers may leak
cookies to other unintended sites.

Best regards,

Tatsuhiro Tsujikawa