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

Hervé Ruellan <herve.ruellan@crf.canon.fr> Thu, 22 January 2015 17:55 UTC

Return-Path: <Herve.Ruellan@crf.canon.fr>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3043F1ACE87; Thu, 22 Jan 2015 09:55:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.26
X-Spam-Level:
X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 zX1xQl_c7CN1; Thu, 22 Jan 2015 09:55:43 -0800 (PST)
Received: from inari-msr.crf.canon.fr (inari-msr.crf.canon.fr [194.2.158.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA3011ACE8A; Thu, 22 Jan 2015 09:55:39 -0800 (PST)
Received: from mir-msr.corp.crf.canon.fr (mir-msr.corp.crf.canon.fr [172.19.77.98]) by inari-msr.crf.canon.fr (8.13.8/8.13.8) with ESMTP id t0MHtZki025355; Thu, 22 Jan 2015 18:55:35 +0100
Received: from Antiope.crf.canon.fr (antiope.fesl2.crf.canon.fr [172.19.70.56]) by mir-msr.corp.crf.canon.fr (8.13.8/8.13.8) with ESMTP id t0MHtZQl005874; Thu, 22 Jan 2015 18:55:35 +0100
Received: from timor.intra-usr.crf.canon.fr (172.20.8.117) by Antiope.crf.canon.fr (172.19.70.56) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 22 Jan 2015 18:55:34 +0100
Message-ID: <54C13996.2030906@crf.canon.fr>
Date: Thu, 22 Jan 2015 18:55:34 +0100
From: =?windows-1252?Q?Herv=E9_Ruellan?= <herve.ruellan@crf.canon.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>, "Black, David" <david.black@emc.com>, Martin Thomson <martin.thomson@gmail.com>
References: <CE03DB3D7B45C245BCA0D243277949362DE459@MX104CL02.corp.emc.com>, <CABkgnnUwNQUcFg5w5HFpSQrAUxtbqG_UN-_WDGop1eqqoCS+Aw@mail.gmail.com> <1421779730757.42642@crf.canon.fr> <CE03DB3D7B45C245BCA0D243277949362E9050@MX104CL02.corp.emc.com> <B42673AB-2819-42F5-BC63-6418449FC030@piuha.net>
In-Reply-To: <B42673AB-2819-42F5-BC63-6418449FC030@piuha.net>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [172.20.8.117]
X-ClientProxiedBy: Antiope.crf.canon.fr (172.19.70.56) To Antiope.crf.canon.fr (172.19.70.56)
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/AhnFmk4ndNFEBOo5kLp_srzqDas>
Cc: "fenix@google.com" <fenix@google.com>, "General Area Review Team \(gen-art@ietf.org\)" <gen-art@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Subject: Re: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-httpbis-header-compression-10
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Jan 2015 17:55:44 -0000

Jari,

On 01/22/2015 01:22 PM, Jari Arkko wrote:
>> 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?

To complement my previous response to David, I think that there are no 
existing header fields that would clearly end up on the list. Some of 
them are good candidates for using the "never indexed literals" 
mechanism, but it mostly depends on how they are used. As Martin 
reported from Firefox implementation, a short cookie should probably be 
protected by this mechanism. But it's a rule of thumb: this cookie could 
convey some uninteresting data or your badly encrypted bank password.

Hervé.

>
> Jari
>