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

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(_dot_)black(_at_)emc(_dot_)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(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie]
Sent: Friday, January 23, 2015 10:45 AM
To: Jari Arkko; Hervé Ruellan
Cc: Martin Thomson; Black, David; ietf(_at_)ietf(_dot_)org; General Area 
Review

Team

(gen-art(_at_)ietf(_dot_)org); fenix(_at_)google(_dot_)com; 
ietf-http-wg(_at_)w3(_dot_)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

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