Subject: Re: [hybi] deflate-stream and masking

From: Greg Wilkins <[email-masked]>
Date: Wed, 20 Jul 2011 12:34:40 +1000

I've just noticed that the w3c is currently intending to make support
for deflate-stream mandatory!

  http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917

This moves this extension from being useless, but mostly harmless, to
being a major impost on servers and intermediaries.
If the browser make this mandatory, then servers will obviously have
to support it at a cost of extra CPU, extra buffers but for no
significant savings in bandwidth.
Intermediaries that wish to act on frame boundaries will also have to
implement it.

This illustrate that having silly options always puts you at risk of
people taking you up on those options.

This extension is demonstrably broken and needs to be either fixed or removed.

regards

On 20 June 2011 16:33, Greg Wilkins <[email-masked]> wrote:
> As part of my continuing campaign against including deflate-stream in
> the specification as a standard extension, I did a quick test of how
> well it works when applied to masked frames.
>
> I took a days worth of traffic from an IRC channel and wrapped it up
> as JSON messages sent as websocket frames.
> There were 487 message that looked like:
>
>     {channel:"#webtide", username:"tbecker", text:"joakime: jenkins
> had issues pulling from github a couple of times  last week"}
>
> As an unmasked WS stream, it was 50675 bytes, and as a masked stream
> is was 52623 bytes.
> I then compressed both these streams with gzip and got 13306 bytes for
> unmasked and 51704 bytes for the masked!!!!
>
> So for this very typical example, masking was sufficiently random to
> completely negate the benefits of compression.
>
> So the deflate-stream "extension" is:
>
>  + next to useless for inbound traffic
>  + breaks all the rules of what an extension can do
>  + is potentially vulnerable to injection as attackers can send
> repeated patterns that may subvert masking
>  + can be replaced by the in-frame compression extension already proposed.
>  + was inserted in the draft with little or no discussion and without
> clear consensus.
>
> Can I call for a straw poll of who wants to keep this extension in the spec?
>
>
>
> regards
>

---

From: Brian <[email-masked]>
Date: Wed, 20 Jul 2011 02:50:09 -0700

+500.  deflate-stream has always been utterly ridiculous in light of
masking.  It really should get the axe, and with extreme prejudice.  Why is
it still in the spec?  I don't recall anyone citing a reasonable reason for
keeping it, but there have been many very good arguments against it.  It's
not even very clearly specified in the document -- when I implemented it in
my Flash client, I had to read the source code of Andy Green's
implementation to figure out how it was supposed to work -- his
implementation became my specification for the extension.

Brian

On Tue, Jul 19, 2011 at 7:34 PM, Greg Wilkins <[email-masked]> wrote:

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: "Arman Djusupov" <[email-masked]>
Date: Wed, 20 Jul 2011 13:58:56 +0300

> +500.  deflate-stream has always been utterly ridiculous in light of
masking. 

Actually when the frame is relatively large, deflate-stream compression does
reduce the size of the payload. For example one of my tests involved sending
a 2MB XML file as a single masked frame which resulted in 90% compression
(i.e. transferred size was a tenth of the original file). So the
"deflate-stream" extension  is not completely useless, it's just very
situational.

> Brian

With best regards,

Arman

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian
Sent: Wednesday, July 20, 2011 12:50 PM
To: Greg Wilkins
Cc: Hybi
Subject: Re: [hybi] deflate-stream and masking

Brian

This extension is demonstrably broken and needs to be either fixed or
removed.

regards

---

From: Philipp Serafin <[email-masked]>
Date: Wed, 20 Jul 2011 14:10:21 +0200

However, for the same scenario, deflate-frame will have at worst
identical, possibly better results. But unlike deflate-stream,
deflate-frame will archieve the same results in a lot of other
scenarios, too.

Am 20.07.2011 12:58, schrieb Arman Djusupov:
> Actually when the frame is relatively large, deflate-stream
> compression does reduce the size of the payload. For example one of my
> tests involved sending a 2MB XML file as a single masked frame which
> resulted in 90% compression (i.e. transferred size was a tenth of the
> original file). So the "deflate-stream" extension  is not completely
> useless, it's just very situational.
>
>  
>
> > Brian
>
>  
>
> With best regards,
>
> Arman
>
>  
>
>  
>

---

From: Justin Lee <[email-masked]>
Date: Wed, 20 Jul 2011 11:02:06 -0700

Thought I'd replied on list...
---------- Forwarded message ----------
From: "Justin Lee" <[email-masked]>
Date: Jul 20, 2011 8:48 AM
Subject: Re: [hybi] deflate-stream and masking
To: "Philipp Serafin" <[email-masked]>

For what it's worth, I haven't bothered implementing deflate-stream on
glassfish because of the concerns here. Removing it would not bother me a
bit. I vote for removing or replacing it.

---

From: David Endicott <[email-masked]>
Date: Wed, 20 Jul 2011 14:09:38 -0400

Unlurking to agree.

When it was optional it was avoidable and non-impairing.   It should not be
mandatory.

+6.02 x10^23 votes for removal from specification (which when deflated is
just +1, I believe)

---

From: "Alexander Philippou" <[email-masked]>
Date: Wed, 20 Jul 2011 21:28:22 +0300

But currently it is an extension and thus optional, isn't it?

From: [email-masked] [mailto:[email-masked]] On Behalf Of David Endicott
Sent: Wednesday 20 July 2011 21:10
To: Brian
Cc: Hybi; Greg Wilkins
Subject: Re: [hybi] deflate-stream and masking

Unlurking to agree.     

When it was optional it was avoidable and non-impairing.   It should not be mandatory.    

+6.02 x10^23 votes for removal from specification (which when deflated is just +1, I believe)

+500.  deflate-stream has always been utterly ridiculous in light of masking.  It really should get the axe, and with extreme prejudice.  Why is it still in the spec?  I don't recall anyone citing a reasonable reason for keeping it, but there have been many very good arguments against it.  It's not even very clearly specified in the document -- when I implemented it in my Flash client, I had to read the source code of Andy Green's implementation to figure out how it was supposed to work -- his implementation became my specification for the extension.

Brian

regards

---

From: David Endicott <[email-masked]>
Date: Wed, 20 Jul 2011 14:55:00 -0400

> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917

If I cannot avoid it in my implementations (because browsers make it
mandatory), then I'm strongly opposed.

If it remains an optional extension, then I revert to a Don't Care position.

On Wed, Jul 20, 2011 at 2:28 PM, Alexander Philippou <[email-masked]>wrote:

> But currently it is an extension and thus optional, isn't it?****
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *David Endicott
> *Sent:* Wednesday 20 July 2011 21:10
> *To:* Brian
> *Cc:* Hybi; Greg Wilkins
>
> *Subject:* Re: [hybi] deflate-stream and masking****
>
> ** **
>
> Unlurking to agree.     ****
>
> ** **
>
> mandatory.    ****
> ** **
> just +1, I believe)****
> ** **
> ** **
> On Wed, Jul 20, 2011 at 5:50 AM, Brian <[email-masked]> wrote:****
>
> implementation became my specification for the extension.****
>
> ** **
>
> Brian****
>
> ** **
>
> On Tue, Jul 19, 2011 at 7:34 PM, Greg Wilkins <[email-masked]> wrote:**
> **
>
> regards****
> https://www.ietf.org/mailman/listinfo/hybi****
>
> ** **
>
>
> https://www.ietf.org/mailman/listinfo/hybi****
>
> ** **
>

---

From: Patrick McManus <[email-masked]>
Date: Wed, 20 Jul 2011 15:43:13 -0400

> > http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917

The bug references the editor's draft (i.e. a work in progress) of the
API, which I would hope could still be changed.

Specifically what it does is, as I read it, is mandate that clients
implementing the JS API (i.e. browsers) must request exactly one
extension in the handshake ("deflate-stream"). It does not require that
the server accept it (indeed it notes what happens to the js attributes
if the server does not - interoperation continues without compression)
so I don't think we can fairly say that it makes deflate-stream support
mandatory in anything other than browsers and then only actually use it
when servers acquiesce.

More concerning is that it effectively bans any other transport
extensions in browsers.

This obviously doesn't match the expected use of protocol extensions,
which is a much bigger space than just transport compression. Even if
the RFC contained a perfect deflate-frame which was specified by the
API, it still interacts poorly with mux or anything else that
implementations might want to do at the transport layer. I don't
understand why the JS API is even participating in such a direct way.
(specifying that compression applies to the messages which could be used
to make the decision on what extensions to negotiate would be a more
indirect and at least on the face of it sensible way to go).

There are no changes the IETF WG can make to the ietf-draft that can fix
this mismatch.

As for compression, the most productive thing to do seems to me to be to
define in a separate draft deflate-frame and push it through the
adoption/standardization process. No matter what is defined the
extensions mechanism should (and does!) provide a mechanism for
migration for any sensible protocol implementations.

While I don't want to go to the mat for deflate-stream it certainly has
a number of use cases where it does well - most downstream traffic of >
tiny-sized messages, and large upstream messages - so I'm not in the
camp of "just throw it out".

---

From: "Alexander Philippou" <[email-masked]>
Date: Wed, 20 Jul 2011 22:46:43 +0300

I vote for keeping it in the spec as it is now – an optional extension. Otherwise we will either remove deflate-stream and ship the protocol w/o compression and be subject to understandable criticism, or we will start discussing which is the optimal compression and further delay standardization until we complete deliberations. Otoh if we proceed with the spec as is then compression will be there, it will be optional, and we can return to add additional compression methods in the immediate future. No harm done to keep it in the spec as is, imho. Let’s ship. 

From: David Endicott [mailto:[email-masked]] 
Sent: Wednesday 20 July 2011 21:55
To: Alexander Philippou
Cc: Hybi
Subject: Re: [hybi] deflate-stream and masking

I'm basing my position on Greg's comment above that:

>  <http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917

If I cannot avoid it in my implementations (because browsers make it mandatory), then I'm strongly opposed.

 

On Wed, Jul 20, 2011 at 2:28 PM, Alexander Philippou <[email-masked]> wrote:

 

Unlurking to agree.     

 

Brian

regards

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 20 Jul 2011 13:48:53 -0600

<hat type='individual'/>

On 7/20/11 1:43 PM, Patrick McManus wrote:

> a number of use cases where it does well - most downstream traffic of>

My reading of the discussion is that people don't necessarily want to 
throw out deflate-stream, but they don't think it belongs in the base 
spec and they would prefer to see it defined in a separate draft, just 
as you propose for deflate-frame.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 20 Jul 2011 20:00:05 +0000

<As individual>

That is my reading as well. 

<as chair>

Patrick, would you be able to own that separate spec?

> -----Original Message-----
> Sent: Wednesday, July 20, 2011 12:49
> To: Patrick McManus
> Cc: Hybi
> > As for compression, the most productive thing to do seems to me to be
> > to define in a separate draft deflate-frame and push it through the
> > While I don't want to go to the mat for deflate-stream it certainly
> > has a number of use cases where it does well - most downstream traffic
> > of> tiny-sized messages, and large upstream messages - so I'm not in
> > the camp of "just throw it out".
> 
> My reading of the discussion is that people don't necessarily want to throw out
> deflate-stream, but they don't think it belongs in the base spec and they would
> prefer to see it defined in a separate draft, just as you propose for deflate-frame.
> 
> Peter
> 
> --
> Peter Saint-Andre
> https://stpeter.im/
> 
>

---

From: Patrick McManus <[email-masked]>
Date: Wed, 20 Jul 2011 16:04:26 -0400

I really believe the base spec must have a compression definition.

The point of my message was that the W3C editor's draft should not turn
into a change in direction on compression on our part because the scope
of that issue is much greater.

---

From: John Tamplin <[email-masked]>
Date: Wed, 20 Jul 2011 16:29:19 -0400

> of that issue is much greater.

I agree with concerns that deflate-stream is less useful than it was
originally since C->S masking has been added, but that doesn't mean it is of
no use at all.  It was originally added to provide "better than nothing"
compression and an example extension in the spec.  Those benefits still
exist, so I would prefer not to simply remove it.

I have no objection to replacing it with deflate-frame if we can get
agreement on it quickly.

I also don't understand Ian Hickson's position, but I don't think that
alters how we define the wire protocol and should be addressed there and not
here.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: David Endicott <[email-masked]>
Date: Wed, 20 Jul 2011 16:36:04 -0400

Whereas, I really believe it shouldn't.   (But not enough to delay
realization of WS)

TCP doesn't have compression.  HTTP does.    TCP is a transport layer.  HTTP
is an application layer.   Websockets is transport layer.  Et voila, my
reasoning.

I've always understood WS as a protocol that defines how content is
exchanged asynchronously between "web" peers.   It is a framing mechanism
for TCP.   It is not an application layer (it doesn't define "verbs", like
GET, POST, HEAD, etc.).    Transport layers should be content agnostic.
Compression is a function of that which uses the transport layer (ie.
application layer).    But, I've said this before, and there is no reason
to belabor the point.

If I have to implement the extension as a mandatory component, I'll be
pissed off, but I'll do it.   My needs for a non-XHR kludge to get async
communication out-weighs my distaste for the extension.  I understand other
peoples needs may differ from mine.

On Wed, Jul 20, 2011 at 4:04 PM, Patrick McManus <[email-masked]>wrote:

> throw out

---

From: John Tamplin <[email-masked]>
Date: Wed, 20 Jul 2011 16:44:36 -0400

> application layer).    But, I've said this before, and there is no reason

The point is that practically all content which will be going over
WebSockets will benefit from compression (see my experiments documented here
a year and a half ago, which included clients sending binary data).  Without
compression built into the spec, developers may be forced into a position of
continuing to use XHR hacks because the lack of compression makes WS slower
(for example, Google Instant search).

---

From: David Endicott <[email-masked]>
Date: Wed, 20 Jul 2011 16:55:51 -0400

Agreed.   The vast majority of (unencrypted, unmasked, unmangled) content
will benefit from compression.   That is a truth I cannot debate.

My use cases will not.    My "slowness" concern is latency, not throughput.
  My traffic will be many small messages and arrives at the WS layer already
encrypted, so compression doesn't work for me to any great extent.   The
turn-around latency of XHR is my biggest concern.   The HTTP
request/response cycle is my problem.   WS solves my latency concerns, and
beyond that I'd like it to just stay out of my way.

I acknowledge that other peoples needs will differ from mine.   I'm just
lazy enough to want to avoid doing work I don't need.

On Wed, Jul 20, 2011 at 4:44 PM, John Tamplin <[email-masked]> wrote:

> On Wed, Jul 20, 2011 at 4:36 PM, David Endicott <[email-masked]>wrote:
>>

---

From: John Tamplin <[email-masked]>
Date: Wed, 20 Jul 2011 16:58:21 -0400

> lazy enough to want to avoid doing work I don't need.

Then even if the w3c position that all clients request deflate-stream
stands, then your server is free to refuse that extension.  Likewise if
deflate-frame is requested.

---

From: David Endicott <[email-masked]>
Date: Wed, 20 Jul 2011 17:05:40 -0400

My reading and my concern (and the de-lurking to comment) is that it seems
its possible the client might request it, get refused and close the
connection instead of continuing.

But, of course, browsers would never do anything like that to influence
protocol implementations, would they?

On Wed, Jul 20, 2011 at 4:58 PM, John Tamplin <[email-masked]> wrote:

>
>
> On Wed, Jul 20, 2011 at 4:55 PM, David Endicott <[email-masked]>wrote:
>
>> My use cases will not.    My "slowness" concern is latency, not
>> throughput.   My traffic will be many small messages and arrives at the WS
>> layer already encrypted, so compression doesn't work for me to any great
>> extent.   The turn-around latency of XHR is my biggest concern.   The HTTP

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 20 Jul 2011 23:11:01 +0200

On Wed, Jul 20, 2011 at 10:46:43PM +0300, Alexander Philippou wrote:
> I vote for keeping it in the spec as it is now ??? an optional extension. Otherwise we will either remove deflate-stream and ship the protocol w/o compression and be subject to understandable criticism, or we will start discussing which is the optimal compression and further delay standardization until we complete deliberations. Otoh if we proceed with the spec as is then compression will be there, it will be optional, and we can return to add additional compression methods in the immediate future. No harm done to keep it in the spec as is, imho. Let???s ship. 

The issue is important for intermediaries. They will have to uncompress
then compress stream in order to forward it. This can be extremlely
expensive in terms of CPU usage and added latency, and I already expect
that a number of intermediaries will recompress with null-compression
in order to save CPU cycles where they can. This will result in an
inflated data stream in the end and higher latencies.

So I vote for removing it and quickly work on defining the deflate-frame
extension as well.

Regards,
Willy

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 21 Jul 2011 12:29:15 +1000

On 21 July 2011 05:48, Peter Saint-Andre <[email-masked]> wrote:
> My reading of the discussion is that people don't necessarily want to throw
> out deflate-stream, but they don't think it belongs in the base spec and
> they would prefer to see it defined in a separate draft, just as you propose
> for deflate-frame.

My reading is that there is a mix of opinions.  Some want it thrown
out, others want to keep it.

What I want to know is how (yet again) has a feature with such divided
support made it into the spec.  Why does this WG insist on putting non
consensus features into the spec and then having the argument to
remove them or not.   The status quo should not be to have a
non-consensus feature included.    It should be for the proponents of
a feature to make their case for inclusion and not for the opponents
to make the case for exclusion.

While it would be good for the base spec to have both compression and
an exemplar extension - that is no reason to just accept any old
extension that is neither good compression nor a good exemplar.

I also understand the argument that deflate-frame should just be
written up in another draft - by why does that not also apply to
deflate-stream?

If we are going to have a favoured son, can't we pick the healthy one
with some good prospects rather than the black sheep that is going to
end up dead or in jail?

regards

---

From: John Tamplin <[email-masked]>
Date: Wed, 20 Jul 2011 22:37:15 -0400

> to make the case for exclusion.

At the time, it wasn't divided.  I don't recall any serious objections at
the time it was proposed and included in the spec, including from you.
 Since then, we added masking which reduces the value in the client->server
direction, but it still has value since most of the large data will be going
from the server to the client.

---

From: David Endicott <[email-masked]>
Date: Wed, 20 Jul 2011 22:47:39 -0400

You sound frustrated, Greg.    I understand that.

On the one hand, we could throw our hands up in frustration and either start
over, or fork the existing work.   Either way, the browser vendors would
need to ratify (by implementing) the protocol.

On the other hand, we could push the current design to standardization, so
that the browser vendors can do final implementation and we all can start
using the 20% of it that isn't borked.  Of course, if we remove a feature or
three beforehand, then the browser folks have to do less and can ship
sooner.

Please try to forgive the dreamers who have gilded our kitchen sink.   It is
a thrilling and intoxicating thing to do protocol design - it leads one to
do stuff because you can imagine it, not because it's actually needed.

I'd be happy to help with whichever of the above courses of action that
 gives me a lightweight asynchronous persistant connection between scripts
running in an easily available, off the shelf, bog standard browser client
and whatever server abomination I come up with, as soon as possible.

On Wed, Jul 20, 2011 at 10:29 PM, Greg Wilkins <[email-masked]> wrote:

> throw

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 20 Jul 2011 20:49:54 -0600

On 7/20/11 8:37 PM, John Tamplin wrote:

> most of the large
> data will be going from the server to the client.

Doesn't that depend on the application?

/psa

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 21 Jul 2011 17:02:56 +1000

> the time it was proposed and included in the spec, including from you.

I don't recall any discussion at all about the extension.   There was
some talk about the effect of compression, to which there was a
response that spoke against stream compression
http://www.ietf.org/mail-archive/web/hybi/current/msg01811.html   The
deflate-stream extension then just appeared in the a draft...  I can't
actually find any thread that proposed it's addition.   I've looked
several times and failed to find any discussion.

Note that I'm not saying that somebody has done some evil deception to
get this into the spec.  Just that when objections have been raised,
then the default position should be that the feature is excluded
unless rough consensus can be achieved.

On 21 July 2011 12:47, David Endicott wrote:
> You sound frustrated, Greg.

Because this is an process anti-pattern that I think is mostly
responsible for much of the difficulties in this WG.   When an idea is
put into the spec, then it has unfair advantage over alternate ideas
and the entire discussion is tainted by the natural tendency to status
quo. Also I just don't understand why when there are many opponents to
this optional feature that we don't just drop it and let the
extensions be proposed in their own drafts and prosper or otherwise on
their own merits - not because they lucked out and became the favoured
son of the core specification.   I'm seen the results of the J2EE
specification process where favoured-son have been picked (Servlets,
no JSPs, no JSFs, no ....) and it is a disaster.

regards

---

From: John Tamplin <[email-masked]>
Date: Thu, 21 Jul 2011 04:48:21 -0400

> several times and failed to find any discussion.

"hybi deflate-stream" found it immediately for me in my mailbox, and
then it was easy to find the other threads from there.

Patrick first discussed it in a thread starting at
http://www.ietf.org/mail-archive/web/hybi/current/msg04071.html, where
you commented only about allocating bits in a fixed manner and how
extensions were named, nothing about the basic operation of the
extension.

Patrick then made an official proposal in the thread starting at
http://www.ietf.org/mail-archive/web/hybi/current/msg04117.html.

The only dissent was me suggesting changing the name from deflate to
deflate-stream, so it went into the next revision of the spec.

> unless rough consensus can be achieved.

I believe the first objections to it were raised months after it was
added to the spec, only after we had argued through masking.  So, I
think it is not correct to say that this was added to the spec over
objections and then it is unfairly harder to remove later.  There were
cases earlier where the previous editor did take unilateral action to
put new things into the spec, but that has not been the case here.

Once we do agree on something, I think it is entirely correct that
there is a higher bar necessary to remove it or else we will never
make progress.  Having new information to bring to the discussion,
such as after we added masking, is an adequate reason to reopen the
discussion, which is what we have been doing.

Personally, I think having a weak compression extension in the base
spec is better than no compression at all, so I would object to
removing it but would not object to replacing it with deflate-frame,
if doing so does not delay finalizing the spec.

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 21 Jul 2011 19:31:49 +1000

John,

I do recall the first thread, but it is all about framed based
compression.  This was a well discussed thread with 30 posts from 10
authors.   There was good support for frame based compression, a bit
of dissent about reserved bit and just a hint of support for stream
based compression.

The second thread, I missed at the time and missed again while
searching. It only has 5 responses from 3 authors.  Reading it now, I
see that opinion was split in these responses with yourself still
advocating frame compression.  Hardly wide consensus that could be
classified as "once we do agree on something".

But maybe I'm being a bit precious and this is probably not the best
example of the anti-pattern that I'm whining about.  So I'll stop
whipping this particular dead horse.

Regardless, there was significant opposition to stream compression
then (pre masking) and there is more now.    I think we are setting a
very low  quality/consensus standard for this extension.   But having
said all this before, I'll now go easy on this not-so-healthy horse.

cheers

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 24 Jul 2011 22:22:30 +0200

>unmasked and 51704 bytes for the masked!!!!

Deflate streams consist of blocks and the blocks consist of tables and
symbols and the symbols represent either bits from what is compressed,
most of those bits are affected by the mask, and back-references that
instruct a decoder to copy bytes -- which are not affected by the mask.
If you create two files, one has "1234" repeating, the other "abcd" re-
peating, and `gzip` them, only a few bytes will be different. You can
trivially create a Websocket stream with some byte sequence repeating.

If you want to have "GET ..." on the wire, well, that can be just some

  <append x bytes from position y to the output>
  <append x bytes from position y to the output>
  <append x bytes from position y to the output>
  ...

bits in the deflate stream. That's not easy to force because encoders
have many options in how they create the stream regardless of masking,
and masking does make it more difficult, but you are greatly aided by,
for instance, having all bytes in the mask be the same, which is not
generally the case if you try to subvert masking without compression.

Without some accepted proof to that effect, the Working Group cannot
claim that masking notably changes the security properties of the pro-
tocol under deflate-stream, which means it would be safe to use only
where it would be safe to use the same mask for all frames, in which
case you no longer have the "compresses poorly" problem, and it would
clearly rule out implementing it in web browsers that "need" masking.

If the base protocol specification were to have a feature that cannot
be implemented by a very large segment of implementations for security
reasons, it would have to have extremely important benefits; deflate-
stream however doesn't have them. Moreover, there does not seem to be
any kind of consensus that extensions should be able to arbitrarily
modify the on-the-wire format. Either way it should not be in the base
protocol specification.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 26 Jul 2011 12:39:25 +1000

On 25 July 2011 06:22, Bjoern Hoehrmann <[email-masked]> wrote:
...
> Either way it should not be in the base protocol specification.

Chairs / Editors,

can you make a call on this please?    Or at least a plan to resolve the issue.

There have been several calls to remove it with substantial reasons
given.   I think the silence on this matter from chairs/editor is just
encouraging repetition of the arguments.

regards

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 25 Jul 2011 23:12:11 -0400

<hat type='AD'/>

> encouraging repetition of the arguments.

I'll leave discussion of specific issues to the chairs. However, Alexey,
Gabriel, Sal, and I had a meeting tonight about the open issues (Ian has
not yet arrived in Quebec City). These issues will be discussed during
the WG session on Thursday. After that I would expect that the chairs or
editors will quickly close a number of issues, publish consensus calls,
post proposed resolutions, etc.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/