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

Re: Benoit Claise's Discuss on draft-ietf-httpbis-header-compression-10: (with DISCUSS)

From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Thu, 22 Jan 2015 17:08:44 +0000
Message-ID: <54C12E9C.1020505@cs.tcd.ie>
To: Roberto Peon <grmocg@gmail.com>, Barry Leiba <barryleiba@computer.org>
CC: Benoit Claise <bclaise@cisco.com>, The IESG <iesg@ietf.org>, draft-ietf-httpbis-header-compression.all@tools.ietf.org, David <david.black@emc.com>, Black@ietfa.amsl.com, Mark Nottingham <mnot@mnot.net>, httpbis-chairs@tools.ietf.org, HTTP Working Group <ietf-http-wg@w3.org>

Hiya,

I just said this on the iesg telechat, but was asked to respond in
this thread too...

I think this one is fine as-is. I don't see that it'd make sense to have
a list of header fields in the RFC or in a registry. Reason being that
the set to not compress can change as we see new attacks and maybe also
depending on the underlying ciphersuites.

Cheers,
S.


On 22/01/15 16:44, Roberto Peon wrote:
> For my part, if it isn't clear what to do with these (set the never-index
> bit when making a request where the entity causing the request is a 3rd
> party as a stronger defense against CRIME-like attacks), then it really
> should be better documented.
> I'd be happy to see this recommendation added to either the HTTP2 or HPACK
> document and/or discussed more.
> 
> -=R
> 
> On Thu, Jan 22, 2015 at 7:42 AM, Barry Leiba <barryleiba@computer.org>
> wrote:
> 
>>> 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.
>>
>> For what it's worth, BenoƮt, I'm perfectly happy with your DISCUSS for
>> this, even though it's kind of on the edge of the defined process.
>> Making sure the comment is address adequately is important, and we're
>> doing the right thing.
>>
>> There was, in fact, discussion about this, and David did not agree
>> with Martin's response.  I'll note that both Stephen and Kathleen
>> balloted Yes on this document, without mentioning the issue.  On the
>> other hand, as it wasn't copied to the IESG list, they might not have
>> seen it raised.  Let's talk about it with them on the call.
>>
>> Barry
>>
>>
> 
Received on Thursday, 22 January 2015 17:09:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:42 UTC