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

Roberto,

Section 7.1.2 Mitigation has already some text about 3rd parties. Do you 
find it sufficient, or would you prefer having a new paragraph in 7.1.3 
saying that an encoder might choose to use the never-index bit for 3rd 
party header fields?

Hervé.

On 01/23/2015 06:59 PM, Roberto Peon wrote:
> 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
> <mailto: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 <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 <mailto:ietf@ietf.org>; General Area Review Team
>     > (gen-art@ietf.org <mailto:gen-art@ietf.org>); fenix@google.com
>     <mailto:fenix@google.com>; ietf-http-wg@w3.org
>     <mailto: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-----
>
>

Received on Monday, 26 January 2015 17:32:32 UTC