W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2015

Re: Kathleen Moriarty's Yes on draft-ietf-httpbis-header-compression-10: (with COMMENT)

From: Hervé Ruellan <herve.ruellan@crf.canon.fr>
Date: Thu, 22 Jan 2015 19:46:14 +0100
Message-ID: <54C14576.9050409@crf.canon.fr>
To: Richard Barnes <rlb@ipv.sx>, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
CC: The IESG <iesg@ietf.org>, Mark Nottingham <mnot@mnot.net>, "httpbis-chairs@tools.ietf.org" <httpbis-chairs@tools.ietf.org>, <draft-ietf-httpbis-header-compression.all@tools.ietf.org>, "HTTP Working Group" <ietf-http-wg@w3.org>

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.


> --Richard
Received 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