- From: Cory Benfield <cory@lukasa.co.uk>
- Date: Tue, 6 May 2014 10:14:06 +0100
- 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 under-specified. 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