- From: Hervé Ruellan <herve.ruellan@crf.canon.fr>
- Date: Mon, 26 Jan 2015 18:29:19 +0100
- To: "Black, David" <david.black@emc.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Jari Arkko <jari.arkko@piuha.net>
- CC: Martin Thomson <martin.thomson@gmail.com>, "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>
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-----
Received on Monday, 26 January 2015 17:30:02 UTC