On 01/22/2015 07:33 AM, Richard Barnes wrote: > > > On Wed, Jan 21, 2015 at 7:02 PM, Kathleen Moriarty > <Kathleen.Moriarty.ietf@gmail.com > <mailto:Kathleen.Moriarty.ietf@gmail.com>> wrote: > > Kathleen Moriarty has entered the following ballot position for > draft-ietf-httpbis-header-compression-10: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-httpbis-header-compression/ > > > > ---------------------------------------------------------------------- > 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. > > > I had this thought briefly as well, but then it occurred to me that the > degree of compression in HPACK is up to the encoder. In particular, the > encoder can send a header list in which all of the header fields are > uncompressed (literal representation, not Huffman-coded). So in a > pinch, compression can be turned off without having to roll out h3. Yes: this is the fallback if ever HPACK compression is broken in the future by a new attack. Hervé. > --RichardReceived on Thursday, 22 January 2015 18:46:57 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:42 UTC