W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: HPACK problems (was http/2 & hpack protocol review)

From: Cory Benfield <cory@lukasa.co.uk>
Date: Tue, 6 May 2014 10:14:06 +0100
Message-ID: <CAH_hAJH+f1_gThu4VQJpP5saLUbTTwbxXfEALcAfxj=kOw0jdA@mail.gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: "K.Morgan@iaea.org" <K.Morgan@iaea.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "C.Brunhuber@iaea.org" <C.Brunhuber@iaea.org>
On 5 May 2014 16:26, James M Snell <jasnell@gmail.com> wrote:
> FWIW, I am strongly -1 on the use of hpack in http/2. I believe that
> there are (and have proposed/argued for) much less complicated
> alternatives.
> - James

I agree with James and Keith's anonymous reviewer's doubts about
HPACK. Hyper's HPACK code has been a source of pain since I first
wrote it. The spec varies wildly between mind-bogglingly specific
(using 32 octets per-header-table entry as overhead because that's the
size of two 64-bit pointers and two 64-bit integers) and

As an example of the under-specification, consider that the reference
set and header sets are defined as unordered but do not say whether
they may contain duplicate elements. My assumption was that they could
not and so I could assume all implementations will join multiple
values with null bytes, but that assumption has not been made
elsewhere (nghttp2 certainly doesn't). Essentially, the word 'set' is
being used here without clarity about what exactly is meant. Is a
'set' simply an unordered collection? Or is it subject to stronger
constraints (more in line with the computer-science definition of a
set)? I guarantee that I won't be the first person to read the word
'set' and jump to my chosen language's set data structure.

These interop bugs with HPACK are ridiculously difficult to catch. I
didn't find any during live testing or in use, I only found some when
I used the excellent hpack-test-case[1] project to write 500-odd
integration tests. Even this didn't catch everything: my interop
problems with nghttp2 were only found when I submitted hyper's output
to the project, fully four months after I introduced the bug.

Finally, I'm utterly unconvinced that HPACK solves the problem it was
intended to solve: compression-based attacks on TLS-encrypted
sessions. I am not a cryptographer, but I'm quite prepared to believe
that we'll see successful attacks on HPACK in the future.

It could be that I'm simply less competent than everyone else on this
list and no-one else has had the trouble with HPACK that I've had. But
I'm also not a total moron, and the pain I had with HPACK suggests
it's a potential pain-point for a lot of others as well.

-- Cory

[1] https://github.com/http2jp/hpack-test-case
Received on Tuesday, 6 May 2014 09:14:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC