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

[Peter Dunkley <[e-mail]>]

Hello,

Thank you for the review it was very much appreciated, and sorry it has
taken so long to respond.

These and other comments made on the list have been considered and a new
version of the document has been published:
http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-05

I have included some specific responses to each of your comments below.

Thanks again,

Peter


On 11 January 2014 06:01, Ben Campbell <[e-mail]> wrote:

> 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?
>

This document is mainly about adding support for a new MSRP transport
(WebSockets) as per section 6 of RFC 4975, and updating the procedures from
RFC4976 to reflect that authentication MAY happen differently with
WebSockets.  I don't believe the rules on chunk sizes have changed as the
rules for chunking in RFC 4975 just use the term "very large" and aren't
specific at all, and RFC 4976 indicates that relays are allowed to re-chunk.

This document doesn't currently deal with MSRP over WebSocket servers that
are not relays (the CEMA scenario).  There is a TODO for Christer Hormberg
to come up with some words describing this scenario, but for now this is
out-of-scope.


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




The loosing of the security requirements from RFC4976 has now been removed.
Discussion on list appears to have reached the conclusion that the security
provided by secure WebSockets is sufficient to meet the requirements of
RFC4976.

The authors of the document do not believe that any new vulnerabilities
have been added by this work and the text of the document has been updated
to reflect this.


> 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?



Additional context has been added to the text of the document.



-- 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?



I don't believe there is anything different here in the WebSocket context.
 This text is informative and intended to provide some context for the
reader of the document.


> --3



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



This has been removed.


> -- 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?



Some additional text has been added to the document to clarify this point.


>

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



This document doesn't currently deal with MSRP over WebSocket servers that
are not relays (for example, the CEMA scenario).  There is no reason why
you couldn't have an MSRP client on a WebSocket server but this is
out-of-scope for this document.


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



I think that this is very implementation (WebSocket client/server) and
application specific. I don't think guidance is particularly helpful here.


>

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



I don't believe there is any need to map between MSRP URIs and HTTP URIs.

I believe that a WebSocket MSRP client will always connect to it's own
server in the same way that an MSRP client will always connect to it's own
relay.


>

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



The AUTH request is required to establish the connection (at the MSRP
layer) between the client and server.  The Use-Path: header returned in the
200 OK to the AUTH is required for the SDP offer/answer.

The text in the document has been updated to clarify this.



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



The downgrading of security has been removed.


> -- 6, last paragraph:



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



This was implicitly allowed as nothing in the document had removed this
capability from RFC4975.  The text has been updated to make it explicit.


> -- 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?



The downgrading of security has been removed.  Only secure WebSocket (over
TLS) connections are permitted.


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



The MSRP relay that is a WebSocket server can request it by sending a 401
to the AUTH.  The text of the document has been updated to make this clear.


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



These have been added.


>

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?



Use of the WebSocket transport makes no change here.


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



The example has been updated to make this clear.


-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd