Skip to main content

HPACK: Header Compression for HTTP/2
RFC 7541

Yes

(Barry Leiba)

No Objection

(Adrian Farrel)
(Alia Atlas)
(Brian Haberman)
(Joel Jaeggli)
(Pete Resnick)
(Spencer Dawkins)
(Ted Lemon)

Note: This ballot was opened for revision 10 and is now closed.

Barry Leiba Former IESG member
Yes
Yes (for -10)

                            
Jari Arkko Former IESG member
Yes
Yes (2015-01-22 for -10)
David Black's Gen-ART review raised the issue of never-indexed fields, and whether guidance or a list of header fields should be in the document to describe when this option should be used. Has the WG discussed this in the past, and what conclusion did it came to? Are there standardised header fields that would clearly be on such a list, if it were given in the document?
Kathleen Moriarty Former IESG member
Yes
Yes (2015-01-21 for -10)
Thank you for your work on this draft and for the thorough security considerations section.  I do agree with the SecDir reviewer that an early reference to the security considerations section would be useful, please consider adding that.

http://www.ietf.org/mail-archive/web/secdir/current/msg05406.html

Another good point is that while this draft addresses current threats (CRIME), the WG should keep in mind that the attacks could evolve.  This is really just to think ahead with options since HPACK is a relatively new algorithm, and since encryption of compressed headers is known to be somewhat perilous.  It is possible that a clever attacker will develop a new attack in the future (i.e., CRIME++ ) that works against HPACK-compressed header fields.
Richard Barnes Former IESG member
Yes
Yes (2015-01-21 for -10)
Section 2.3.3: "Indices between 1 and the length of the static table..."
The use of 1-based indexing here seems likely to lead to incompatibilities.

Section 3:
Currently, you never say explicitly that a header block is the concatenation of encoded header fields, where each field is encoded according to Section 6.  This would be a good spot to do that.

Section 5.1: "... always finishes at the end of an octet"
It was not immediately clear to me that the "?" bits indicated that an integer need not *begin* at an octet boundary.  It would be helpful to note that here.
Stephen Farrell Former IESG member
Yes
Yes (2015-01-22 for -10)

Excellent stuff! A well-written clear description of a 
reasonably complex thing.
Adrian Farrel Former IESG member
No Objection
No Objection (for -10)

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -10)

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2015-01-21 for -10)
My one question about this was about lack of extensibility of the static table, but I see that some intro text has been added to the editor's copy of the document <http://http2.github.io/http2-spec/compression.html> that speaks to this. Keeping that text would be good imo.
Benoît Claise Former IESG member
(was Discuss) No Objection
No Objection (2015-01-22 for -10)
Similar to Jari's COMMENT.
David Black, part of the combined OPS/GEN-ART review (http://www.ietf.org/mail-archive/web/gen-art/current/msg11197.html) mentions:

The second major issue looks serious - one of the major motivations
for HPACK is to mitigate attacks on DEFLATE (e.g., CRIME) via use of never
indexed fields wrt compression.  The absence of a list of header fields
that MUST use that never indexed functionality appears to be a serious
oversight.

This point was discussed during the IESG telechat and, according to the Sec ADs, this is not an issue: list of header that should never be compressed, will change in response to the attach. Stephen and Kathleen will follow up on the list.
Brian Haberman Former IESG member
No Objection
No Objection (for -10)

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -10)

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (2015-01-21 for -10)
I just wonder if there is a second implementation, the shepherd report is pointing out one.
Pete Resnick Former IESG member
No Objection
No Objection (for -10)

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -10)

                            
Ted Lemon Former IESG member
No Objection
No Objection (for -10)