Skip to main content

Last Call Review of draft-ietf-hybi-permessage-compression-21
review-ietf-hybi-permessage-compression-21-secdir-lc-sparks-2015-06-25-00

Request Review of draft-ietf-hybi-permessage-compression
Requested revision No specific revision (document currently at 28)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-06-24
Requested 2015-06-10
Authors Takeshi Yoshino
I-D last updated 2015-06-25
Completed reviews Genart Last Call review of -22 by Dan Romascanu (diff)
Genart Telechat review of -24 by Dan Romascanu (diff)
Secdir Last Call review of -21 by Robert Sparks (diff)
Opsdir Last Call review of -22 by Warren "Ace" Kumari (diff)
Assignment Reviewer Robert Sparks
State Completed
Request Last Call review on draft-ietf-hybi-permessage-compression by Security Area Directorate Assigned
Reviewed revision 21 (document currently at 28)
Result Has issues
Completed 2015-06-25
review-ietf-hybi-permessage-compression-21-secdir-lc-sparks-2015-06-25-00

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).

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.

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?

It would be good to point to, or provide, a discussion of how the extension
negotiation mechanism in WebSockets is meant to be protected.

RjS