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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxx> 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@xxxxxxxx; General Area Review Team
(gen-art@xxxxxxxx); fenix@xxxxxxxxxx; ietf-http-wg@xxxxxx
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-----



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]