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@xxxxxxx> 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@xxxxxxxxx]
> 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-----