HPACK: Header Compression for HTTP/2
draft-ietf-httpbis-header-compression-12

[Ballot comment]
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.

[Ballot discuss]
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.

Could I ask one of you to place a Discuss to ensure that these concerns
are addressed?

====================
I haven't had the time to read the draft (shocking I know). So I'm unclear at this point if the feedback is DISCUSS/COMMENT-worthy, but ... I've got a very high respect for David's technical reviews. In many years of review, it's the first time he directly asked me to file a DISCUSS. So I want to go to the bottom of this issue. If this approach is clumsy (yes, I know, the DISCUSS should be in my name, not on behalf of David), I could also "DEFER" this draft. 
I also see that the authors/David engaged in the discussion on the ietf@ietf.org list. Good.

[Ballot comment]
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?

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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  that speaks to this. Keeping that text would be good imo.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-httpbis-header-compression-10 which is currently in Last Call, and has the following comments:

We understand that this document does not contain a standard IANA Considerations section.
After examining the draft, IANA understands that, upon approval of this document, there
are no IANA Actions that need completion.

It is helpful to have the IANA Considerations section of the document in place upon
publication for clarity purposes.


If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (HPACK - Header Compression for HTTP/2) to Proposed Standard


The IESG has received a request from the Hypertext Transfer Protocol WG
(httpbis) to consider the following document:
- 'HPACK - Header Compression for HTTP/2'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-01-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This specification defines HPACK, a compression format for
  efficiently representing HTTP header fields, to be used in HTTP/2.

Editorial Note (To be removed by RFC Editor)

  Discussion of this draft takes place on the HTTPBIS working group
  mailing list (ietf-http-wg@w3.org), which is archived at [1].

  Working Group information can be found at [2]; that specific to
  HTTP/2 are at [3].

  The changes in this draft are summarized in Appendix D.1.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-httpbis-header-compression/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-httpbis-header-compression/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/2506/
  http://datatracker.ietf.org/ipr/2015/

# Summary

Mark Nottingham is the Document Shepherd and Working Group Chair. Barry
Leiba is the responsible Area Director.

This specification defines HPACK, a compression format for efficiently
representing HTTP header fields, to be used in HTTP/2.

We intend this to be published as a Proposed Standard.

# Review and Consensus

We have enjoyed active participation from a broad community, including
browser vendors, intermediaries (such as CDN and proxy vendors), server
vendors and protocol library authors; this includes both commercial
vendors and open source libraries.

Our current implementation list is at:
  https://github.com/http2/http2-spec/wiki/Implementations
 
Additionally, we have had participation and review from the
non-implementing HTTP community itself. We have substantial external
interest from the Web performance community as well.

We have also coordinated with the W3C, giving them regular updates
through the liaison and the TAG.

Process-wise, we were chartered to do this work in August 2012, with a
submission deadline of November 2014. We have treated that date
seriously, so as to bound the commitment of the developers and
implementers involved. As a result, we had a fairly high frequency of
interim meetings (six in two years), used both to discuss issues and to
hold interop events.


# Intellectual Property

The authors are currently working with their employers' respective legal
teams to update their existing disclosures, which have been brought to
the Working Group's attention.

See
for a full list of disclosures regarding this document.

# Other Points

This document has no considerations for IANA. It does not currently have an
IANA Considerations section; this will be inserted upon the next update.

IDNits reports a number of other warnings; they are all spurious.

# Summary

Mark Nottingham is the Document Shepherd and Working Group Chair. Barry Leiba is the responsible Area Director.

This specification defines HPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/2.

We intend this to be published as a Proposed Standard.

# Review and Consensus

We have enjoyed active participation from a broad community, including browser vendors, intermediaries (such as CDN and proxy vendors), server vendors and protocol library authors; this includes both commercial vendors and open source libraries.

Our current implementation list is at:
  https://github.com/http2/http2-spec/wiki/Implementations
 
Additionally, we have had participation and review from the non-implementing HTTP community itself. We have substantial external interest from the Web performance community as well.

We have also coordinated with the W3C, giving them regular updates through the liaison and the TAG.

Process-wise, we were chartered to do this work in August 2012, with a submission deadline of November 2014. We have treated that date seriously, so as to bound the commitment of the developers and implementers involved. As a result, we had a fairly high frequency of interim meetings (six in two years), used both to discuss issues and to hold interop events.


# Intellectual Property

The authors are currently working with their employers' respective legal teams to update their existing disclosures, which have been brought to the Working Group's attention.

See  for a full list of disclosures regarding this document.

# Other Points

Note any downward references (see RFC 3967) and whether they appear in the DOWNREF Registry (http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry), as these need to be announced during Last Call.

This document has no considerations for IANA. It does not currently have an
IANA Considerations section; this will be inserted upon the next update.

IDNits reports a number of other warnings; they are all spurious.