Subject: Stephen Farrell's Discuss on draft-ietf-httpbis-cice-02: (with DISCUSS)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 02 Sep 2015 08:39:43 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-httpbis-cice-02: Discuss

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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-cice/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Did anyone think through the potential for this kind of
change to interact with attacks like BREACH? [1] It
looks like at least some of the mitigations mentioned on
[1] would not apply to requests, or possibly not, so I
suspect there is something to say here. If that analysis
was not done, I think someone ought look at it. If that
analysis was done, shouldn't there be some mention here? 

   [1] http://breachattack.com/

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Sep 2015 10:52:46 +1000

Something like this, perhaps?
  http://httpwg.github.io/specs/rfc7540.html#rfc.section.10.6

Cheers,

> On 3 Sep 2015, at 1:39 am, Stephen Farrell <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 Sep 2015 02:01:04 +0100

>   http://httpwg.github.io/specs/rfc7540.html#rfc.section.10.6

Yes and no.

No. The URL above is for HTTP/2 and this is a header usable in
HTTP/1.1 so is not the same. Adding this to a system that is
currently safe wrt BREACH is also perhaps not the same as doing
HTTP/2 from scratch and ending up safe wrt BREACH.

But more importantly, yes, I'm asking about the kind of analysis
that lead to the section 10.6 you point at.

S.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 3 Sep 2015 10:48:49 +0200

> HTTP/2 from scratch and ending up safe wrt BREACH.

Note that the spec doesn't really introduce compression for 
client->server. This feature has been around for ages. All the spec does 
is make feature discovery and diagnostics easier.

I agree that it would be good to have security considerations with 
respect to gzip encoding in HTTP/1.1, but that ultimately belongs into 
the revisions of RFC 7230 and 7231, not here. (I just opened 
https://github.com/httpwg/http11bis/issues/6>).

> that lead to the section 10.6 you point at.

There was no analysis because the use of compression in this 
client->server direction really really isn't new at all.

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 Sep 2015 10:47:23 +0100

Hi Julian,

> is make feature discovery and diagnostics easier.

I don't understand your last sentence above. Isn't this a signal
that will cause request compression to be turned on in cases when
it wasn't previously? If not, then I at least misread the text.
If so, then the "All" in your sentence doesn't seem correct.

> https://github.com/httpwg/http11bis/issues/6>).

Ok good.

> client->server direction really really isn't new at all.

Hmmm.

S.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 3 Sep 2015 12:09:41 +0200

> If so, then the "All" in your sentence doesn't seem correct.

It may lead to more compression to be used; but compression can (and is) 
used without this feature.

> ...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 4 Sep 2015 17:04:32 +0200

Right now we have:

> 6. Security Considerations
>
> This specification does not introduce any new security considerations beyond those discussed in Section 9 of [RFC7231].

...so that's clearly not helping. How about:

"This specification introduces only discovery of supported content 
codings and diagnostics for requests failing due to unsupported content 
codings. As such, it doesn't introduce any new security considerations 
over those already present in HTTP/1.1 (see Section 9 of [RFC7231]) and 
HTTP/2 (Section 10 of [RFC7540]).

However, the point of better discoverability and diagnostics is to make 
it easier to use content codings in requests. This might lead to 
increased usage of compression codings such as gzip (Section 4.2.3 of 
[RFC7230]), which, when used over a secure channel, can be subject to 
compression side-channel attacks such as BREACH (Section 10.6 of 
[RFC7540], [BREACH]). At the time of publication, it was unclear how 
BREACH-like attacks can be applied to compression in HTTP requests."

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Sep 2015 16:29:55 +0100

Hi Julian,

That change would be great thanks,

S.

On 04/09/15 16:04, Julian Reschke wrote:
>> This specification does not introduce any new security considerations
>> beyond those discussed in Section 9 of [RFC7231].
>

---

From: Julian Reschke <[email-masked]>
Date: Sat, 5 Sep 2015 20:02:17 +0200

> That change would be great thanks,

Ok,

the proposed changes made based on the IESG feedback can be seen here: 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-cice-latest-from-previous.diff.html> 
(individual commits: 
<https://github.com/httpwg/http-extensions/commits/master/draft-ietf-httpbis-cice.xml>).

Are people ok with these changes? Should I go ahead an submit a new draft?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 7 Sep 2015 11:23:17 +1000

LGTM.

> On 6 Sep 2015, at 4:02 am, Julian Reschke <[email-masked]> wrote:
> 
> the proposed changes made based on the IESG feedback can be seen here: <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-cice-latest-from-previous.diff.html> (individual commits: <https://github.com/httpwg/http-extensions/commits/master/draft-ietf-httpbis-cice.xml>).
>