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

Roberto Peon <grmocg@gmail.com> Fri, 23 January 2015 17:59 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 367941ACCC7; Fri, 23 Jan 2015 09:59:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham
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 HakDAzrcVPoJ; Fri, 23 Jan 2015 09:59:27 -0800 (PST)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBBDF1ACCE7; Fri, 23 Jan 2015 09:59:26 -0800 (PST)
Received: by mail-oi0-f44.google.com with SMTP id a3so7703532oib.3; Fri, 23 Jan 2015 09:59:25 -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=CMG/MzCkWsPehtLvy3AhRNAtANo12cqJ47xH8rpVNO4=; b=SX+rZeJc7fHXNoGwvGKj/eyOuXMcr4F59Nt7Shon8bTL4IrGWKwJvoqCWVSjTIDDNr U8SoCTehtcBkEa9cAqzgi96E8ivKSpPUq2TJAkf2vow+Ij2nW8FcLAFuwZvkhKxbKB4n 62AoRE5DTfW/Kb//fN6fr1qWB+O+JKCqE35RxS8D8vm/uJgyQHf1JxLstOMavr/HmMEu U6TIITn/LiiW6DGWO90xD7Kwqhq3UWMHVQOd4zJxvojvJW6lsLn/zSrKv02xU1btVbPy nX/K8fTQP6WYjWu8wP0vaoRw48txhcY0UFQkroRJZePbONcVriq32OPPJYd/37x9BNIs lBIw==
MIME-Version: 1.0
X-Received: by 10.60.78.137 with SMTP id b9mr5232364oex.36.1422035965023; Fri, 23 Jan 2015 09:59:25 -0800 (PST)
Received: by 10.76.91.69 with HTTP; Fri, 23 Jan 2015 09:59:24 -0800 (PST)
In-Reply-To: <CE03DB3D7B45C245BCA0D24327794936310012@MX104CL02.corp.emc.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>
Date: Fri, 23 Jan 2015 09:59:24 -0800
Message-ID: <CAP+FsNeN_ko1W1vfKw2HZ4OJLs6g2XtwBw9rM7sceHTUj8x2ZQ@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: "Black, David" <david.black@emc.com>
Content-Type: multipart/alternative; boundary=089e0111c0588d9bb6050d558cee
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/5eg3FfZGBxPXC2KC0jm4yrJYcpg>
X-Mailman-Approved-At: Fri, 23 Jan 2015 10:41:57 -0800
Cc: "ietf@ietf.org" <ietf@ietf.org>, "General Area Review Team \(gen-art@ietf.org\)" <gen-art@ietf.org>, "fenix@google.com" <fenix@google.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, =?UTF-8?Q?Herv=C3=A9_Ruellan?= <herve.ruellan@crf.canon.fr>, 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: Fri, 23 Jan 2015 17:59:30 -0000

What Herve had so far LGTM.
I think we should also have some blurb in there about the
3rd-party-request-origin stuff, since it isn't the most obvious attack
vector.
As a reminder, this attack is:
Allow the client to successfully create a connection and send a request
which should populate a secret.
Now, with the intercepting agent, kill any packets sent to the client from
the server, but send acks to the client, observing sizes of the packets the
client is sending.
The 3rd party site to which the client is connected (which is colluding
with the intercepting agent) then instructs the client to make many
requests (until the flow control window is exhausted) to test its many
hypothesis, none of which are visible to the server.

Using the never-index bit when a request is originates with a 3rd party
helps to mitigate this in many cases, and some mention of this use-case
would be useful, I suspect.
-=R



On Fri, Jan 23, 2015 at 8:51 AM, Black, David <david.black@emc.com> 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-----
>