Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt

[Ian Fette (イアンフェッティ) <[e-mail]>]

On Wed, Jun 8, 2011 at 4:03 PM, Greg Wilkins <[e-mail]> wrote:

> Wow - that was a more extensive rewrite than I was expecting - but
> most of the text looks to be good improvements - good work!
>
>
> However 4.2 says
>
>     The payload data is defined as extension data concatenated wit
> application data.
>
> and this is reflected elsewhere in the document.   Concatenation is
> not the correct paradigm as this prohibits a compression or encrypting
> extension which changes the entire payload.
>

Not really. We used to say the "body" of the frame was extension data
followed by application data, indeed the payload len has always meant
len(ext)+len(app). This re-write takes a lot of the sections that used to
talk about this and now just talks about "payload" where payload data is
extension data followed by application data, just as before. It doesn't
prevent a compressing or encrypting extension -- the extension is free to
modify the application data. [perhaps that point needs to be called out more
explicitly somewhere]. For instance, a compressing extension could have a
small amount of "extension data" such as an instruction to reset state and
contain "application data" (the compressed data).


> I think we should simply say that the payload data is the application
> data as processed by all the negotiated extensions.
>
>
I think I would prefer to to keep some distinction of what data is purely
for the extensions and what data is the actual data being passed by the
protocol, at least conceptually. We can make it clearer that the extensions
modify payload data, and at some points the distinction may not be crystal
clear, but I think the distinction is still useful (for instance, by saying
that a pong must have identical application data, we don't have to say that
the payload is identical.)


>
> Section 4.4, bullet point 3 is formatted as a bullet point, when it is
> really a sub clause of the previous bullet point.  Also the Note about
> control frames is formatted as another bullet point.
>


yes, sorry


>
> I also think this section needs another point like:
>
>  * The fragments of one message may not be interleaved between the
> fragments of another message unless an extension has been negotiated
> that can interpret the interleaving.
>

anyone else have thoughts here? it seems reasonable to me but I'd like to
hear other opinions.


>
>
> 4.8 says:
>
>   o  Extension data may be placed in the payload data before the
>      application data.
>
> As above, this prevents compression/encrypting extensions.  Extensions
> must be allowed to arbitrarily mutate the application data.
>

see prior explanation earlier in this response


>
>
> 9.2.1 Compression
>
> I still maintain that this extension should not be supported - it
> breaks all the rules the spec defines for extensions - specifically it
> mutates the framing.   There is an alternative compression proposal
> available for in frame compression that would comply with the rules of
> extensions (assuming we remove the concatenation restriction above).
>
>
How do others feel about keeping it / yanking it?


>
> In section 10, the draft says:
>
>   The biggest security risk when sending text data using this protocol
>   is sending data using the wrong encoding.  If an attacker can trick
>   the server into sending data encoded as ISO-8859-1 verbatim (for
>   instance), rather than encoded as UTF-8, then the attacker could
>   inject arbitrary frames into the data stream.
>
> I don't think this is true - not since we dropped sentinel encoded frames.
> Length encoded frames are safe to send arbitrary data and there is no
> possibility of any payload being interpreted as a frame in the
> datastream.
>

I agree the text needs to be changed, but perhaps rather than killing it
entirely, it can be rewritten as a more general statement of please be
careful with encodings, as when you tell a recipient something is utf-8,
they may make assumptions that will prove problematic if you send them
something like iso-8859-1 instead, or at the least may cause
misinterpretation or loss of data.


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