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

Roberto Peon <grmocg@gmail.com> Mon, 26 January 2015 21:48 UTC

Return-Path: <grmocg@gmail.com>
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 03CAB1B2A8F; Mon, 26 Jan 2015 13:48:48 -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 63cHzMQef-sm; Mon, 26 Jan 2015 13:48:45 -0800 (PST)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A37E21B2A8D; Mon, 26 Jan 2015 13:48:45 -0800 (PST)
Received: by mail-oi0-f49.google.com with SMTP id a3so9426155oib.8; Mon, 26 Jan 2015 13:48:45 -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=lBJpu/5H7xHN0N/jIk0BcLZtBm4DEDSHI8zfczr4Pag=; b=XNifLHzGprOeHNQHRZSPmH/t69lxAKav5ehVzRfpApB+8LB6bLKIqzvTPoujgVKEAi JrwU13q+Zz/KCE0lxnZLS8Np6GUKlQxASMQKAz07Z1ZRllaBmV4Pp23mp3CjbwTixp7u Ik9zHHvykG55SZYeWhfV3z2qIWPzVY2b1fO+utqAVZhyfa3x6F6/OYPmC9OWpPTlmPLV c7ynqSXLg9iLgmpYcwR8N5+B66En8ImIZudF1rYC4i/h4nt4UH0bs0AIZ0GAChX/wwc3 3LtcqDetHbDVBEQtxtoY1SmiAjTANhDGEYiymfWytMH/BNAAmNYo+FKeyNlb46vYttDb KzNw==
MIME-Version: 1.0
X-Received: by 10.182.33.102 with SMTP id q6mr14197208obi.79.1422308924910; Mon, 26 Jan 2015 13:48:44 -0800 (PST)
Received: by 10.76.91.69 with HTTP; Mon, 26 Jan 2015 13:48:44 -0800 (PST)
In-Reply-To: <54C6796F.5000104@crf.canon.fr>
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> <54C13996.2030906@crf.canon.fr> <0A78F531-9E8E-4ED1-BD8F-AAE70684DB24@piuha.net> <CABkgnnVBCK-yy9WitKCVqitcXssOHgBc2c+3UeRO09mAHa3A8Q@mail.gmail.com> <54C23CC5.7050901@cs.tcd.ie> <54C267DE.5040202@crf.canon.fr> <ABFED3B4-D37D-4498-9280-3C071EB00892@piuha.net> <54C26C8E.50507@cs.tcd.ie> <CE03DB3D7B45C245BCA0D24327794936310012@MX104CL02.corp.emc.com> <54C6796F.5000104@crf.canon.fr>
Date: Mon, 26 Jan 2015 13:48:44 -0800
Message-ID: <CAP+FsNfzT6dOUdU3wUZHwJ3pgzxE882DqKeSx0gkQAPSCYT0VQ@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: =?UTF-8?Q?Herv=C3=A9_Ruellan?= <herve.ruellan@crf.canon.fr>
Content-Type: multipart/alternative; boundary=047d7b5d90b53af19c050d951aa1
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/Q7LhGFPyV-zg7KzL9hFeKOl4WQw>
Cc: "ietf@ietf.org" <ietf@ietf.org>, "fenix@google.com" <fenix@google.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "General Area Review Team \(gen-art@ietf.org\)" <gen-art@ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
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: Mon, 26 Jan 2015 21:48:48 -0000

Herve--
I'm not sure that the text in 7.1.2 is explicit enough to be understood--
I'd be hard-pressed to define "guess" reliably. The bit that is missing,
imho, is that the provenance of the request is from a 3rd party, which is
reason to be suspicious.

An alternate wording:
An encoder seeing many 3rd party requests which contain keys whose values
never match may decided to ensure that such keys are never indexed when
going to that site, as this effectively prevents probing of the compression
context, and, if not malicious, would likely offer no benefit from indexing
anyway.

-=R



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

> I tried to integrate all these comments, as well as those of Martin on
> GitHub into: https://github.com/http2/http2-spec/pull/704
>
> Hervé.
>
>
> On 01/23/2015 05:51 PM, Black, David wrote:
>
>> This sort of guidance will definitely be a useful addition.   A little
>> more wordsmithing on Stephen's proposed text follows:
>>
>>    The decision on whether a header field is ok to
>>    compress or
>>    not is highly dependent on the context. As a generic
>>    guidance, header fields used for conveying highly valued
>>    information, such as the Authorization or Cookie header
>>    fields, can be considered to be on the more sensitive
>>    side. In addition, a header field with a short value
>>    has potentially a smaller entropy and can be more at
>>    risk. We know that compressing low-entropy sensitive
>>    header fields can create vulnerabilities so such
>>    cases are most likely the ones to not compress today.
>>    Note though that the criteria to apply here may evolve
>>    over time as we gain knowledge of new attacks.
>>
>>
>> OLD
>>    We know that compressing low-entropy sensitive
>>    header fields can create vulnerabilities so such
>>    cases are most likely the ones to not compress today.
>>    Note though that the criteria to apply here may evolve
>>    over time as we gain knowledge of new attacks.
>> NEW
>>    We currently know that compressing low-entropy sensitive
>>    header fields can create vulnerabilities so compression
>>    of such fields ought to be avoided.
>>    This guidance may evolve
>>    over time as we gain knowledge of new attacks.
>>
>> Thanks,
>> --David
>>
>>  -----Original Message-----
>>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
>>> Sent: Friday, January 23, 2015 10:45 AM
>>> To: Jari Arkko; Hervé Ruellan
>>> Cc: Martin Thomson; Black, David; ietf@ietf.org; General Area Review
>>> Team
>>> (gen-art@ietf.org); fenix@google.com; ietf-http-wg@w3.org
>>> Subject: Re: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-httpbis-
>>> header-compression-10
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>>
>>>
>>> On 23/01/15 15:35, Jari Arkko wrote:
>>>
>>>>
>>>>  I made a proposal at
>>>>> https://github.com/http2/http2-spec/pull/704
>>>>>
>>>>
>>>> Looked reasonable to me.
>>>>
>>>
>>> Me too. Quibbling, I'd suggest:
>>>
>>> OLD:
>>>
>>>   The decision on whether a header field is sensitive or
>>>   not is highly dependent on the context. As a generic
>>>   guidance, header fields used for conveying highly valued
>>>   information, such as the Authorization or Cookie header
>>>   fields, can be considered to be on the more sensitive
>>>   side. In addition, a header field with a short value
>>>   has potentially a smaller entropy and can be more at
>>>   risk.
>>>
>>> NEW:
>>>
>>>   The decision on whether a header field is ok to
>>>   compress or
>>>   not is highly dependent on the context. As a generic
>>>   guidance, header fields used for conveying highly valued
>>>   information, such as the Authorization or Cookie header
>>>   fields, can be considered to be on the more sensitive
>>>   side. In addition, a header field with a short value
>>>   has potentially a smaller entropy and can be more at
>>>   risk. We know that compressing low-entropy sensitive
>>>   header fields can create vulnerabilities so such
>>>   cases are most likely the ones to not compress today.
>>>   Note though that the criteria to apply here may evolve
>>>   over time as we gain knowledge of new attacks.
>>>
>>> Cheers,
>>> S.
>>>
>>>
>>>
>>>
>>>
>>>> jari
>>>>
>>>>  -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1
>>>
>>> iQEcBAEBAgAGBQJUwmyOAAoJEC88hzaAX42iJKkIAJtbLdBsQe12+yyg47yupU9x
>>> xbJJ8WZj7vN9Owc9DbzPUczcejjxPUETWwiJ4gzGEnqOTgkH4Ljbt3DnZO1OrdwL
>>> J5sdie+/x85WuimEgz8GLeOvHe3vyKAJzRIGuX4c4PFgxQ2EBQTJwMM9/qBx9Wp4
>>> gLNSMmvd0DT8mfozQokju4H4SsxEgFWIERpDO1Has/3ska0u0qhCrJgIdSSWWn08
>>> yvsjoPDfp+SPEJOa+vWoWqP971QXaGsm5lnhPDLTJ+u06cWpzeQerOEmS3dMYX4A
>>> 0gcR73olUgS9gqVQ/HIYDKLxsOX3DXH0QSJhHOgYrE6GNPUX2bz7npN0PP7+x0s=
>>> =Txbn
>>> -----END PGP SIGNATURE-----
>>>
>>
>