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