(adding the hybi list)
It seems to me that this effectively adding an actor (the intermediary)
, and defining (not as explicitly as I think it needs to be) protocol
mechanics for that actor in ways that the base specification did not
anticipate.
I'm not comfortable that the consequences of these new mechanics
(specifically - that the intermediary can directly participate in the
extension negotiations, and change the results) are well understood. The
additions to the text you propose will certainly help point out that
there might be some, and the message that the endpoint won't have
insight into how its messages are handled beyond the intermediary needs
to be prominent.
But I wonder if the mechanics of an intermediary _changing the protocol
signalling_ is something the working group should explicitly work on
writing down?
RjS
On 6/30/15 3:42 AM, Takeshi Yoshino wrote:
Thank you for review, Robert.
On Thu, Jun 25, 2015 at 6:18 AM, Robert Sparks <rjsparks(_at_)nostrum(_dot_)com
<mailto:rjsparks(_at_)nostrum(_dot_)com>> wrote:
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
Summary: Ready with issues
(fwiw, I also reviewed up through version -24).
Section 7 (Intermediaries) should be more explicit that it's talking about
an intermediary doing compression on one side and not (or doing different
compression) on the other.
(If that's not what it's trying to set up, please clarify).
OK. So, I'd like to change the text as follows:
When an intermediary proxies ... Per-message Compression of messages
received from one peer, and then forward the messages to the other
peer, if the intermediary ...
It's not clear from reading RFC6455 that the idea of intermediaries
changing the contents of the websocket extension negotiation mechanism was
considered - have I missed the text in that RFC that discusses that?
Are there other extensions that suggest similar behavior? It's not
immediately clear that the protocol mechanics do the right thing when the
different negotiations on each side of the proxy fail differently.
It's not well discussed in RFC6455. Right. AFAIK, there's no such
extension defined, yet.
I understand that this text (intermediary section in the I-D) works
just not to disallow change of compression but there's nothing in
RFC6455 that guarantees that such transformation doesn't cause any
issue with other infrastructure of the WebSocket protocol.
I believe that unless any extension that interferes with the other
negotiated extensions (e.g. counting the number of negotiated
extensions, relying on PMCE, etc.), the core WebSocket protocol
(things defined in RFC6455) should work. If such an extension is
introduced, it would be just considered to be incompatible with PMCEs,
or that extension should describe how to coordinate with change on
PMCE in the intermediaries section of its RFC.
I think this is more reasonable than prohibiting change on Per-message
Compression by intermediaries.
This also seems to put an endpoint in a position where it has no say on
what an intermediary does with the traffic on the other side of it. Is that
worth discussing in the document?
Ah, right. Maybe some text like:
"It's not guaranteed that the PMCE which an endpoint has negotiated in
the opening handshake is preserved in the whole path to the peer
endpoint."
It would be good to point to, or provide, a discussion of how the extension
negotiation mechanism in WebSockets is meant to be protected.
As a general discussion to cover other extensions (if they want. by
referring to this to-be-RFC) like the section defining terms to
complement RFC6455 [1]?
[1]
https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-24#section-3