[RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04

[Ben Campbell <[e-mail]>]

[Oops, I meant to copy dispatch. Sorry for the repeat. Please include dispatch on any discussion.]

Hi,

Mary asked me to do a review of draft-pd-dispatch-msrp-websocket-04 from the perspective of an alleged MSRP expert. (Actually she requested it for 03, but since 04 is available, I reviewed that one. Please be advised that my knowledge of WebSocket is somewhat limited.

I think this draft is on the right track and generally well written. But I have two general areas of concern, which I think I've mentioned before:

I'd like to see more detail on the expected support (and behavior) for a WebSocket MSRP Relay when dealing with 4975/4976 clients and relays. For example, would it be acceptable to build a WebSocket MSRP Relay that would only talk to WebSocket clients, and not support "legacy" MSRP relays and clients at all? Since this draft introduces some new rules on chunk sizes, how would a WebSocket MSRP relay handle it if a "legacy" peer did not follow them? 

The security considerations section needs considerably more meat. I'd like to see a discussion of the security implications of downgrading the 4976 MUST requirement for TLS between a client and a server, as well as the use of the MSRPS scheme if the WebSocket connection is not protected.

It would be worth a discussion of any other TLS requirements that differ between MSRP/WebSocket and 4975/4976. For example, are the certificate matching rules the same for WebSocket as for MSRP/TLS? Is there any requirement that the domain names match between the WebSocket and MSRP layers? (i.e. could I authenticate as example.com, but except traffic for example.net?)

From higher level perspective, does the use of WebSocket introduce potential web oriented vunerabilities that native MSRP wouldn't have? (e.g., sidejacking of authentication cookies over non-protected connections?)

specific comments:

-- Abstract and Introduction:

The idea that WebSocket enables communication between clients and servers needs a bit more context. One assumes that clients and servers could talk to each other before the advent of WebSocket. When does it make sense to use MSRP/WebSocket rather than MSRP/TLS or MSRP/TCP?

-- section 1, last bullet:

This point needs more context. The need to apply policy to a messages is already one of the justifications for 4976. Likewise, MSRP using SIP already offers varying degrees of authentication. How is the need for these things different in the WebSockets context?

--3

I am not happy with the downgrade of of the TLS requirement between client and relay. I recognize that WebSocket

-- 4.2:

MSRP only allows a "binary" transfer encoding. I'm not sure it makes sense to use text frames, even for text content. If text frames are allowed, do you need to verify that only text-based content-types are negotiated at the signaling layer? Does introduce a mapping requirement for WebSocket relays, for example if a WebSocket client sends text frames towards a "legacy" peer?

-- 5.1, 1st paragraph:

Is it impossible to have an MSRP _client_ implemented on a WebSocket _server_? (For example, an robot endpoint for human-to-machine or machine-to-machine communication?)

-- 5.1, last paragraph:

Can you offer guidance on a reasonable or maximum chunk size? It may be worth suggesting a minimum size beneath which MSRP messages should not be chunked. Can a MSRP chunk in a WebSocket frame be interrupted? (I note the examples have interruptible chunks.)

nit: Indented paragraphs are usually considered parenthetical explanations. It's generally not a good idea to put 2119 normative language in them.

-- 5.2.1: 

Is there ever a need to map between MSRP URIs and HTTP URIs? Is a WebSocket MSRP client expected to always connect to it's own server, or would it ever connect to a WebSocket server that it learned about in the offer/answer? (e.g a WebSocket server acting on behalf of the peer?) Is there any requirement that the MSRP URI domain name matches the HTTP domain name in any way? (In particular, can a server that presented a TLS cert for one or more domains accept MSRP URIs for a domain that was not included in the cert?)

-- 5.3.1:

It seems ambiguous when you allow the connection to be authenticated at the WebSocket layer whether the AUTH request is still required. I assume it is, since all the examples use it. But it's not clear to me from the language in this section.

-- 5.3.2:

This issue has given me heartburn for WebSocket in general. It's not as big of an issue for protocols that do not have MUST level requirements for TLS. But I really don't like downgrading a security related MUST from 4976. As I mentioned above, if we are going to do so, we need a thorough discussion of the security implications. (For example, do we introduce a requirement to ensure MSRPS URLs are never used for unprotected links? Do we need to worry about "legacy" endpoint users that assume that the peer's client to relay connection is always protected? 

It seems like we should have some general IETF policy on this, as I'm sure MSRP is not the first place it has come up. But in general, while I am sensitive to "existing code" or "API" limitations preventing some requirements from being MUSTs, I am personally less sympathetic when it means downgrading an already existing security requirement. 

-- 6, last paragraph:

Seems lile they also need to be prepared to receive bodiless SEND keep-alives  from the peer, especially from legacy peers.

-- 7:

Is there any requirent (in WebSockets or otherwise) that authentication cookies only be tranferred over protected connections? Does this introduce a sidejacking attack into MSRP?

-- 7, last paragraph: " ... authentication MAY be requested at MSRP protocol level."

Who can request it? Just the client by sending an AUTH? (Still not clear if AUTH is expected when authenticating at the WebSocket layer.) Also, you might consider avoiding 2119 language in a section marked as "non-normative".

-- 8:

I'd like to see an example with authentication included. It would also be good to see an example where the peer has it's own relay.

All the examples assume default settings for the Failure-Report and Success-Report header fields. There's no other mention of them. Does anything change with those as a result of using WebSocket?

-- 8.4:

Does this not still assume the offer/answer exchange from the previous example? Why not include the "bob -> alice" message in the previous example? (Or are we assuming Bob initiated the session negotiation this time?)



Thanks!

Ben.