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:49 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 5D7B51B2A8B; Mon, 26 Jan 2015 13:49:30 -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 e5dyDtybNREZ; Mon, 26 Jan 2015 13:49:28 -0800 (PST)
Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CC991B2A9A; Mon, 26 Jan 2015 13:49:22 -0800 (PST)
Received: by mail-ob0-f182.google.com with SMTP id gq1so10186420obb.13; Mon, 26 Jan 2015 13:49:21 -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=FN9H3xis2DyuCdTx7DwxSBYO+3JMkQMBhHU3CsUmICc=; b=r+/MIQVPfs1QyL8bPWn0MKMMvqq4pEULnJZNULpm92d+0n+Ft1jvVb2GRqpoXiWcPi txc7ppz6YOOc4yr2983v8s8F1nYbpMJZFAKwbXh5K7v4u+9zl5VSkq2O+82RJWRL2r8c 8frojmf8yyTYp3zNQ/51Hfqpm8/eijvOt8UZBQSq6oB9dfUpADmF5EpjJduGiBn2rc3O ARWWX1kdQkne5d9MUMGy3wJvR8UINdS1emgNXReEFG9Bctl6Ybyd64CkQod75AxdWxvD S6yGxG391xJofYOgfg5eqPyvrIzkdVhvicMQQVkpkGxAm4iHRydCCANRMllbwQiI4nVY ydfw==
MIME-Version: 1.0
X-Received: by 10.182.98.164 with SMTP id ej4mr11082367obb.0.1422308961375; Mon, 26 Jan 2015 13:49:21 -0800 (PST)
Received: by 10.76.91.69 with HTTP; Mon, 26 Jan 2015 13:49:21 -0800 (PST)
In-Reply-To: <CAP+FsNfzT6dOUdU3wUZHwJ3pgzxE882DqKeSx0gkQAPSCYT0VQ@mail.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> <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> <CAP+FsNfzT6dOUdU3wUZHwJ3pgzxE882DqKeSx0gkQAPSCYT0VQ@mail.gmail.com>
Date: Mon, 26 Jan 2015 13:49:21 -0800
Message-ID: <CAP+FsNePViw8rANC2L6KufTiYy-E8mCLZH06znqXZ1HENNLhtg@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=047d7b2e41f4675e5a050d951c3f
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/2fboOHGNPkD0Wf2773ZRHh9YoZA>
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:49:30 -0000

s/decided/decide/

I'm sure it can be further massaged before it is document ready
-=R

On Mon, Jan 26, 2015 at 1:48 PM, Roberto Peon <grmocg@gmail.com> wrote:

> 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-----
>>>>
>>>
>>
>