Subject: [hybi] extension data in draft-7

From: Greg Wilkins <[email-masked]>
Date: Wed, 27 Apr 2011 12:00:34 +1000

All,

I see that the definition of extension data in draft -7 has been
removed from the framing diagram.
However it still exists in the ABNF for the framing, so it should be
removed from there also.

I think this is a reasonable thing to do, as it is impossible to
generally say if extension data is prepended or appended to payload
data.  Consider a compressing extension, this will mutate all the
payload.

Furthermore I think the first bullet point in section 4.8 should be changed from

   o  Extension data may be placed in the payload before the application
      data.

to

   o  Extensions may mutate payload data that will increase and/or
decrease the total size of the payload.

I also believe we should drop 8.2.1 Compression as a known extension.
There have been several threads pointing out issues with this
extension and it follows none of the mechanisms identified in 4.8 and
is a mutation of framing.

I think we should explicitly prohibit extensions from changing the framing.

---

From: Brian McKelvey <[email-masked]>
Date: Tue, 26 Apr 2011 19:49:23 -0700

+1

Sent from my iPhone

---

From: Patrick McManus <[email-masked]>
Date: Tue, 26 Apr 2011 23:44:35 -0400

> I also believe we should drop 8.2.1 Compression as a known extension.

I'm vehemently opposed to removing it - especially at this stage. Its a
shame the group rejected multiplexing in the base spec - let's not make
the omission of basic components worse by not including any compression
scheme at all either.

As defined it has some shortcomings. For some uses cases they are pretty
minor, for others fairly significant. It is all optional in any event.
There is nothing preventing deflate-stream from being supplanted by
another preferred extension defined separately.

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 27 Apr 2011 16:02:13 +1000

> the omission of basic components worse by not including any compression

But it is not removing extension data as a concept,  it is just generalising it.

Rather than saying extension data must be prepended to the payload,
the proposal is to say that an extension can mutate the payload in an
arbitrary way: prepending, appending or changing data as it likes.

regards

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 27 Apr 2011 18:29:08 +1000

oops Andy just pointed out I misread Patricks response.

He is opposed to taking out compression.

Note that I'm not advocating taking out compression, just taking out
deflate-stream.  I'd be very happy to see the in frame compression
extension take it's place.

The arguments against deflate-stream extension are:

 + it does not compress very well because the data is masked.
 + it breaks framing and there was never consensus for it to do that.
 + it does not conform to any of the criteria of what an extension can
do (section 4.8)
 + because frame boundaries are obfuscated, intermediaries will be
less efficient in forwarding frames.
 + there is a viable alternate proposal that does not suffer these issues.

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 28 Apr 2011 09:26:25 +1000

One more reason to drop deflate-stream (or to replace it with in frame

>  + there is a viable alternate proposal that does not suffer these issues.

+ because gzip encoding uses predictable bit patterns to represent
repeated patterns, then it is possible with deflate-stream that an
attacker can form data that compresses predictably, even when masked,
and thus will be able to control the bytes sent on the wire and can
spoof requests.

cheers