The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)
RFC 7977
Yes
(Ben Campbell)
No Objection
(Alia Atlas)
(Alvaro Retana)
(Deborah Brungard)
(Jari Arkko)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 13 and is now closed.
Ben Campbell Former IESG member
Yes
Yes
(for -13)
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(2016-08-04 for -13)
Unknown
In Section 10, last para: Any security considerations specific to the WebSocket protocol are detailed in the relevant specifications ([RFC6455] and [RFC4975]) and are considered outside the scope of this document. The certificate name matching and cryptosuite selection will be handled by the browser, and the browser's procedures will supercede those specified in [RFC4975]. Certificate name matching is described by RFC 6455, so the above text is not accurate. (The point about certificate matching from [RFC4975] not being used is correct though.)
Alia Atlas Former IESG member
No Objection
No Objection
(for -13)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(2016-08-02 for -13)
Unknown
I see in 5.2.2 that it is acceptable for clients to specify "TCP/MSRP" in an SDP m-line. But then in Section 10 there is the requirement for MSRP-over-websocket traffic to be protected by TLS, and RFC 4976 requires the same for all client-relay communications. What is the use case where a client would signal TCP/MSRP in an m-line while also indicating use of a websocket relay? I'm having trouble understanding why the option to specify TCP/MSRP is needed.
Alvaro Retana Former IESG member
No Objection
No Objection
(for -13)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -13)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -13)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2016-08-04 for -13)
Unknown
Fred Baker <fred@cisco.com> performed the opsdir review.
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2016-08-03 for -13)
Unknown
I see you've addressed Alissa & Mirja's comments, thanks for that. I also agree with Alexey's, but can't find the discussion, so I am not sure mail went out on it.
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2016-08-03 for -13)
Unknown
Nits/minor questions: 1) Please spell out MSRP at the first occurance in the 2. paragraph in the intro and give a reference s/MSRP/MSRP (Message Session Relay Protocol) [RFC4975]/ 2) In section 4.2 the following sentence is not fully clear to me: "The content of text frames MUST be interpreted as binary by WebSocket Clients and Servers." Wouldn't that break if the content of the text frame is actually UTF-8? Wouldn't it be better to ignor text frames? 3) Section 8.2.3 has a copy/paste error: Last transaction should be "F4 200 OK Alice -> a.example.com (transport WSS)" (and not " F4 200 OK Bob -> a.example.com (transport TLS)") 4) Inline with Alissa's comment: These two statement seem to contradict each other: "it is acceptable for an MSRP WebSocket Client to specify the "TCP/MSRP" or "TCP/TLS/MSRP" protocols in the SDP m-line" (section 5.2.2) and "MSRP traffic transported over WebSockets MUST be protected by using a secure WebSocket connection (using TLS [RFC5246] over TCP)." (section 10)
Spencer Dawkins Former IESG member
No Objection
No Objection
(2016-08-03 for -13)
Unknown
I agree with Alissa and Mirja on TCP/MSRP.
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2016-08-04 for -13)
Unknown
The first part of this was a DISCUSS that Ben answered. Thanks for making TLS a MUST-use in section 10. However, that makes me wonder why it's ever ok to not use TLS on the other side of the MSRP relay. I assume that's down to deployments that can't ensure TLS on both sides but that then raises some questions for me that I didn't see answered in the document, so I'd like to briefly check/chat-about those... (and also to ask if you can up the ante as well:-) (1) When both sides of the MSRP relay do want TLS, but the MSRP-relay-as-TLS-client fails to setup the "righthand" (referring to the draft's diagrams) TLS session, say because of a bad cert, what does the browser see? (That may be entirely obvious to someone who knows MSRP and need no change in the draft, but it wasn't clear to me.) (2) If the "righthand" MSRP session is not protected with TLS, then is that fully under the control of the client/browser? IOW, how does the browser/client express a desire that it really really wants TLS on both sides or else to fail? I think that's down to using msrps URIs but am not sure. Again that might be clear to anyone who knows MSRP but I don't:-) Can you clarify? (3) The answer is probably "no" but would it be feasible to say that a client for this MUST only use msrps: URIs? If it were feasible, that'd be good I think. If it's not feaasible, that's a pity, but I'm not asking that you add pretend statements about security we won't get;-) From here on was not a discuss. - I also agree with Alissa's comment about the m= line and am glad to see that change was accepted. - 5.3.1: Why is there no option for TLS client auth here? If you allow cookies, then I don't see why you say nothing about that. - section 7: I don't get why you want/need CORS here - can you explain? (Not sure if something needs stating in the document, but as-is, it's unclear to me.) - 8.1.2 and elsewhere: It'd have been fine to only say once that MRSP doesn't allow line folding:-) - section 9: Thanks! Great to see that. - section 10: Thanks for saying that TLS MUST be used between client/browser and MSRP relay. That's a bit buried down here though - I think it'd have been good to say that at the top of the document too. (I got the wrong initial impression that you were allowing cleartext between the client/browser and MSRP relay from the start of the document.) - section 10: Do you need to add a security consideration saying that the MSRP relay can see the plaintext and that the client/browser shouldn't indicate e2e security to the user? - section 10: Wouldn't it be a good idea to add a statement that TLS as used here ought follow BCP195? (RFC7525)
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -13)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -13)
Unknown