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

[Roberto Peon <[e-mail]>]

s/decided/decide/

I'm sure it can be further massaged before it is document ready
-=R

On Mon, Jan 26, 2015 at 1:48 PM, Roberto Peon <[e-mail]> wrote:

> 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 <[e-mail]
> > 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:[e-mail]]
>>>> Sent: Friday, January 23, 2015 10:45 AM
>>>> To: Jari Arkko; Hervé Ruellan
>>>> Cc: Martin Thomson; Black, David; [e-mail]; General Area Review
>>>> Team
>>>> ([e-mail]); [e-mail]; [e-mail]
>>>> 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-----
>>>>
>>>
>>
>