The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)
draft-pd-dispatch-msrp-websocket-15

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

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.

Fred Baker <fred@cisco.com> performed the opsdir review.

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.

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)

I agree with Alissa and Mirja on TCP/MSRP.

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)