Subject: Re: [dispatch] New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt

From: Peter Dunkley <[email-masked]>
Date: Thu, 07 Mar 2013 15:43:15 +0000

Hello Ben,

I am sorry it took a while to respond to your comments.  I wanted to 
confer with my colleague Gavin Llewellyn (who has been on vacation) 
before responding.

My comments are in-line below.

Regards,

Peter

On 21/02/13 22:23, Ben Campbell wrote:
> ** Major:
>
> -- General: Interworking with legacy relays and endpoints:
>
> I infer that an MSRP WebSocket Server is expected to also act as an ordinary MSRP relay, in that it can talk to legacy relays and clients. Is there a normative requirement for that that I missed? Is it allowed to have an MSRP WebSocket server that only enables communication between WebSocket Clients?
This draft extends RFC4975 and RFC4976 and is intended to increase the 
capabilities of MSRP clients and relays not reduce it.

There is no practical reason to not allow MSRP WebSocket servers to only 
communicate between WebSocket clients, but that is deliberately not an 
aspect that this draft considers.  The intention of this draft is to 
enable MSRP over WebSocket clients to be used in addition to (and with) 
current MSRP clients.

> -- Use of TLS:
>
> I'm very concerned about downgrading the 4976 MUST on use of TLS between a client and a relay that it authenticates to. This seems unacceptable on it's face. You indicate that the client code may have no control over this--can you elaborate?
In a Javascript client running in a browser you can mandate TLS by using 
a wss:// URL.  However:
1) You cannot force mutual TLS or any extended verification - you are 
stuck with what the browser does
2) Self-signed certificates and certificates where 
domain-names/addresses do not match are handled badly by browser 
WebSocket implementations

Point 1 means that you will never get the level of security and 
assurance with TLS for WebSockets that RFC 4976 gives you for ordinary 
MSRP clients.

Point 2: for HTTP you have things like the Firefox add exception dialog 
(or IE/Chrome warning about the certificate page) to help you with 
locally defined certificates.  There is no such thing for WebSockets and 
no obvious way of adding it.  This means that unless you have 
specifically configured each computer to accept the certificate the 
connection establishment will fail.  Properly signed certificates used 
on the Internet will be no problem, but this is a show-stopper if you 
have a large internal deployment.

Because of these points I felt that, while people should be encouraged 
to be as secure as possible, the use of TLS in this case needs to be a 
matter of local policy.  Leaving the strong requirements of RFC 4976 in 
place here would result in either a specification that could not be 
implemented at all, or was simply impractical for many deployments.

It should be noted that the TLS requirements are downgraded only for the 
situation where WebSockets are used.  This change does not affect 
non-WebSocket MSRP relay connections.

> ** Minor:
>
> -- 5.1:
>
> Be careful with the terminology. In MSRP, a "message" means the pre-chunked content. If you split it, each piece is a "chunk". I think you mean to say that each WebSocket message must contain a single MSRP "chunk", correct?
Yes.  I will look at updating the terminology in the next draft.

> Also, are there issues with large chunks? Does the MSRP concept of starting to send large content in a single chunk, but interrupting it if needed work with WebSockets?
WebSocket sends messages in frames.  It is possible to have a 
multi-frame WebSocket message, but doing so is complex and some 
implementations do not fully support this.  As such it makes sense to 
mandate that a chunk sent using MSRP over WebSocket fits within a single 
WebSocket frame.  This places a requirement on an MSRP over WebSocket 
client to chunk large data-sets.  It also places a requirement on an 
MSRP over WebSocket server (which may receive large content from 
non-WebSocket clients) to chunk messages to WebSocket clients.

> -- 7:
>
> Can you offer guidance on what should happen if a server tries to use HTTP Digest at the MSRP layer, but the client doesn't support it? (The reciprocal of "MAY" us usually "MUST". That is, if a device MAY do something, the peer MUST gracefully handle it.)
I can foresee a number of scenarios where WebSocket handshake 
authentication will be sufficient.  It is entirely possible to develop 
an MSRP WebSocket client or MSRP WebSocket server that is intended for 
use in just these scenarios.  As a result I did not want to mandate any 
unnecessary implementation just so that a client can be said to adhere 
to this specification.

Perhaps some slightly different language would be appropriate here? Does 
anyone have any suggestions?

> -- 9.1:
>
> I'd like to see some guidance about server certificate matching. Do the rules in 4976 and 4975 still apply?
Due to the way the browser/Javascript WebSocket APIs work they cannot 
still apply.  This is why the TLS requirement was loosened in section 5.3.2

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 7 Mar 2013 17:31:28 +0100

7 mar 2013 kl. 16:43 skrev Peter Dunkley <[email-masked]>:

> 
> Hello Ben,
> 
> I am sorry it took a while to respond to your comments.  I wanted to confer with my colleague Gavin Llewellyn (who has been on vacation) before responding.
> 
> This draft extends RFC4975 and RFC4976 and is intended to increase the capabilities of MSRP clients and relays not reduce it.
> 
> There is no practical reason to not allow MSRP WebSocket servers to only communicate between WebSocket clients, but that is deliberately not an aspect that this draft considers.  The intention of this draft is to enable MSRP over WebSocket clients to be used in addition to (and with) current MSRP clients.
> 
>> -- Use of TLS:
>> 
> In a Javascript client running in a browser you can mandate TLS by using a wss:// URL.  However:
> 1) You cannot force mutual TLS or any extended verification - you are stuck with what the browser does
> 2) Self-signed certificates and certificates where domain-names/addresses do not match are handled badly by browser WebSocket implementations
> 
> Point 1 means that you will never get the level of security and assurance with TLS for WebSockets that RFC 4976 gives you for ordinary MSRP clients.
> 
> Point 2: for HTTP you have things like the Firefox add exception dialog (or IE/Chrome warning about the certificate page) to help you with locally defined certificates.  There is no such thing for WebSockets and no obvious way of adding it.  This means that unless you have specifically configured each computer to accept the certificate the connection establishment will fail.  Properly signed certificates used on the Internet will be no problem, but this is a show-stopper if you have a large internal deployment.
> 
> Because of these points I felt that, while people should be encouraged to be as secure as possible, the use of TLS in this case needs to be a matter of local policy.  Leaving the strong requirements of RFC 4976 in place here would result in either a specification that could not be implemented at all, or was simply impractical for many deployments.
> 
> It should be noted that the TLS requirements are downgraded only for the situation where WebSockets are used.  This change does not affect non-WebSocket MSRP relay connections.
That the current browser implementation sucks in error handling for websockets is not a reason to lower the bar in the draft. We've successfully raised the bar in regards of security in WebRTC and I hope we can keep the bar high here too.

The problem with the wss implementations was shown at SIPit. Hopefully it's on the participating browser developer's todo list. If not, it should be reported in their bug trackers. It was embarrassing that a javascript app developer couldn't get a proper error code for expired certs or other TLS connection failures.

/O

> WebSocket sends messages in frames.  It is possible to have a multi-frame WebSocket message, but doing so is complex and some implementations do not fully support this.  As such it makes sense to mandate that a chunk sent using MSRP over WebSocket fits within a single WebSocket frame.  This places a requirement on an MSRP over WebSocket client to chunk large data-sets.  It also places a requirement on an MSRP over WebSocket server (which may receive large content from non-WebSocket clients) to chunk messages to WebSocket clients.
> 
>> -- 7:
>> 
> I can foresee a number of scenarios where WebSocket handshake authentication will be sufficient.  It is entirely possible to develop an MSRP WebSocket client or MSRP WebSocket server that is intended for use in just these scenarios.  As a result I did not want to mandate any unnecessary implementation just so that a client can be said to adhere to this specification.
> 
> Perhaps some slightly different language would be appropriate here? Does anyone have any suggestions?
> 
>> -- 9.1:
>> 
> Due to the way the browser/Javascript WebSocket APIs work they cannot still apply.  This is why the TLS requirement was loosened in section 5.3.2
> 
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Peter Dunkley <[email-masked]>
Date: Thu, 07 Mar 2013 16:50:21 +0000

> The problem with the wss implementations was shown at SIPit. Hopefully it's on the participating browser developer's todo list. If not, it should be reported in their bug trackers. It was embarrass…

Hi Olle,

This deals with my point 2 (assuming the browser developers do fix the 
problems), but it really doesn't help with point 1.  Making it possible 
to do this level of extended TLS security for WebSockets in a 
web-browser is surely well outside of something the IETF can do alone?  
After all, it is the W3C that specify the Javascript APIs for managing 
WebSocket connections and these would require significant re-work to 
support this.

I'm all for making things as secure as possible, but I can't see this 
level of security being achievable from a browser any-time soon.

Regards,

Peter

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Mar 2013 01:05:15 +0800

At end

On 3/8/13 12:50 AM, Peter Dunkley wrote:
>
>>>> -- Use of TLS:
>>>>
>>>> I'm very concerned about downgrading the 4976 MUST on use of TLS
>>>> between a client and a relay that it authenticates to. This seems
>>>> unacceptable on it's face. You indicate that the client code may
>>>> have no control over this--can you elaborate?
>>> assurance with TLS for WebSockets that RFC 4976 gives you for
>>> ordinary MSRP clients.
>>>
>>> Point 2: for HTTP you have things like the Firefox add exception
>>> dialog (or IE/Chrome warning about the certificate page) to help you
>>> with locally defined certificates.  There is no such thing for
>>> WebSockets and no obvious way of adding it.  This means that unless
>>> you have specifically configured each computer to accept the
>>> certificate the connection establishment will fail.  Properly signed
>>> certificates used on the Internet will be no problem, but this is a
>>> show-stopper if you have a large internal deployment.
>>>
>>> Because of these points I felt that, while people should be
>>> encouraged to be as secure as possible, the use of TLS in this case
>>> needs to be a matter of local policy.  Leaving the strong
>>> requirements of RFC 4976 in place here would result in either a
>>> specification that could not be implemented at all, or was simply
>>> impractical for many deployments.
>>>
>>> It should be noted that the TLS requirements are downgraded only for
>>> the situation where WebSockets are used.  This change does not affect
>> That the current browser implementation sucks in error handling for
>> websockets is not a reason to lower the bar in the draft. We've
>> successfully raised the bar in regards of security in WebRTC and I
>> hope we can keep the bar high here too.
>>
>> The problem with the wss implementations was shown at SIPit. Hopefully
>> it's on the participating browser developer's todo list. If not, it
>> should be reported in their bug trackers. It was embarrassing that a
>> javascript app developer couldn't get a proper error code for expired
>> certs or other TLS connection failures.
>>
>> /O
>>
>
> Hi Olle,
>

doing MSRP over webrtc data channel would, I think, address these 
security problems.

OTOH it would require waiting for the definition of data channels to be 
completed.

	Thanks,
	Paul

---

From: Peter Dunkley <[email-masked]>
Date: Thu, 07 Mar 2013 17:13:04 +0000

Also at the end

On 07/03/13 17:05, Paul Kyzivat wrote:
> OTOH it would require waiting for the definition of data channels to 
> be completed.
>

As has been discussed in the "Remapping existing protocols..." thread, 
WebRTC data channel is not a great solution for browser to server 
communications.

There are many reasons to use an MSRP relay:
- Regulatory monitoring/logging
- Local policy (within organisation) monitoring/logging
- Interoperation with existing MSRP clients

MSRP over WebRTC data channel would be fine if the use case was secure 
messaging communications between browsers without any requirement for 
logging.  But I think WebSocket is the way to go for use cases that need 
a server involved.

Regards,

Peter

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 7 Mar 2013 18:26:20 +0100

7 mar 2013 kl. 18:05 skrev Paul Kyzivat <[email-masked]>:

> doing MSRP over webrtc data channel would, I think, address these security problems.
> 
> OTOH it would require waiting for the definition of data channels to be completed.

I think that's a different usage model. If you can do peer2peer chat, that works. If the
other party is on a SIP device somewhere within the SIP network, using browser
technology would not work.

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Mar 2013 02:05:15 +0800

On 3/8/13 1:26 AM, Olle E. Johansson wrote:

snip

> technology would not work.

The data channel stuff is being defined first for rtcweb. But that 
doesn't mean it is exclusively *browser technology*, or *web 
technology*. Websockets are *web technology*.

CLUE is going to use the data channel technology for its own clue 
signaling channel. We are doing this for two reasons:

- It will provide a solution that works through nats (with ICE)
   and provides a reliable transport. And rtcweb is doing the work
   of getting it defined, so we don't have to do it.

- We want to make it possible for webrtc clients to be clue endpoints.

So clue components, most of which will not be browsers, will be 
implementing this mechanism. That includes clue conference servers 
(MCUs). Those same servers will probably also use BFCP, so it would be 
convenient if we had BFCP over data channel so browsers could 
participate and the servers could use the same stack for both protocols.

CLUE isn't currently talking about IM, but that could happen in the 
future. If so, MSRP over data channel might also be convenient.

	Thanks,
	Paul