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

[Hervé Ruellan <[e-mail]>]

Jari,

On 01/22/2015 01:22 PM, Jari Arkko wrote:
>> Designing a mechanism to resist an attack but failing to provide guidance
>> (either here or in the main HTTP v2 draft) on how to use it to resist that
>> attack does not solve the actual problem, no matter how clever the
>> mechanism.
>>
>> I hope the Security ADs notice this discussion, because the current
>> situation looks like a security flaw from here (likely to result
>> in insecure implementations, even though the implementations contain
>> the mechanism needed to fix the security problem).
>>
>> If a list of specific fields is not reasonable, some specific guidance on
>> where and why this mechanism needs to be applied is in order, as (IMHO)
>> it is unreasonable to expect the entire global implementer community
>> to have a detailed working command of the CRIME attack and its HPACK
>> implications wrt specific pieces of information exchanged in the HTTP v2
>> protocol.
>
> I am sympathetic to David’s point here, although it is not necessarily clear
> to me that such information needs to be a part of this specific draft; it could
> be defined elsewhere as well.
>
> For what it is worth, I’m doing a review of this document along with Gen-ART
> review comments, and I think where I have ended up is that the above issue
> is a Comment from my perspective (and not a blocking Discuss).
>
> But I’d like to hear some feedback on this point though, or has that
> discussion already happened in the WG in the past? Also, for my
> education, are the standardised header fields that would clearly end
> up on the list, if it existed, or is this only for other
> or future header fields?

To complement my previous response to David, I think that there are no 
existing header fields that would clearly end up on the list. Some of 
them are good candidates for using the "never indexed literals" 
mechanism, but it mostly depends on how they are used. As Martin 
reported from Firefox implementation, a short cookie should probably be 
protected by this mechanism. But it's a rule of thumb: this cookie could 
convey some uninteresting data or your badly encrypted bank password.

Hervé.

>
> Jari
>