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

[Jari Arkko <[e-mail]>]

Thanks for the in-depth review, David. Much appreciated, as always, 
and particularly so with this important draft.

With regards to the fixed design:

>> A few people objected to this on the grounds that this flies in the
>> face of a body of accepted wisdom on extensibility in protocols.  But
>> that flexibility turns out to be contrary to the aforementioned goals.
>> Ultimately, this choice was very clearly and consistently the
>> consensus of the working group.


>   The HPACK format is intentionally simple and inflexible.  Both
>   characteristics reduce the risk of interoperability or security
>   issues based by implementation error.  No extensibility mechanisms
>   are defined; changes to the format are only possible by defining a
>   complete replacement.

I agree.

For the rest, I’m skipping to the main remaining debated point:

>>> That list doesn't exist, because the need to avoid indexing is highly
>>> contextual.  Like padding, I don't expect this feature to be widely
>>> used, because it requires specific knowledge, but it is necessary to
>>> avoid low-entropy secrets from being exposed to CRIME-like attacks.
> 
> 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?

Jari