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

From: Ben Campbell <[email-masked]>
Date: Sat, 11 Jan 2014 15:54:08 -0600

On Jan 10, 2014, at 5:34 PM, Ben Campbell <[email-masked]> wrote:

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

Robert pointed out to me that my comments on this section were truncated. Apparently I'm not qualified for this email gizmo. Here's another try:

I recognize that the WebSocket API limits the application's ability to control the security parameters of the connection. I think this is a general issue for moving application protocols to use WebSocket, that perhaps needs to be addressed in the WebSocket API.  We probably need an whole IETF (or at least RAI+APPS) policy for how to handle this. But MSRP is somewhat unusual in having a "MUST use" TLS requirement, and in the current security climate we need to take a really hard look at anything that weakens the normative security requirements of a messaging protocol.

I don't have an answer for how to proceed, but at a minimum I would like to see considerably more discussion of the implications and any potential mitigation of this in the Security Considerations sections.

---

From: Peter Dunkley <[email-masked]>
Date: Mon, 13 Jan 2014 09:41:19 +0000

On 11 January 2014 21:54, Ben Campbell <[email-masked]> wrote:

>
> I don't have an answer for how to proceed, but at a minimum I would like
> to see considerably more discussion of the implications and any potential
> mitigation of this in the Security Considerations sections.
>

More discussion is certainly needed here.  The reason I chose to downgrade
the security here was purely pragmatic.

As nice as it would be to make the security requirements for MSRP over
WebSockets very strict it would also be utterly pointless as (right now and
for the foreseeable future) it would not be possible to implement.

Regards,

Peter

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: Ben Campbell <[email-masked]>
Date: Mon, 13 Jan 2014 16:43:34 -0600

On Jan 13, 2014, at 3:41 AM, Peter Dunkley <[email-masked]> wrote:

> More discussion is certainly needed here.  The reason I chose to downgrade the security here was purely pragmatic.
> 
> As nice as it would be to make the security requirements for MSRP over WebSockets very strict it would also be utterly pointless as (right now and for the foreseeable future) it would not be possible to implement.

Understood. I think the conversation needs to cover the general case of "how do we handle things when new transport options take security decisions away from the application protocol implementations". MSRP is an especially interesting case due to the MUST USE requirement in RFC 4976.

Maybe that's already been discussed, but if so I've missed it.

Ben.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 29 Jan 2014 16:11:26 +0000

I don’t see why using websockets would require us to get rid of the MUST use TLS. 

The security of relays is a total disaster if you don’t have this so if the MUST be security authenticated goes away for relays, then I suspect this mechanisms is too broken to publish.

Cullen ( in my individual contributor role just to be clear )

On Jan 11, 2014, at 2:54 PM, Ben Campbell <[email-masked]> wrote:

> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 29 Jan 2014 17:42:31 +0100

> The security of relays is a total disaster if you don’t have this so if the MUST be security authenticated goes away for relays, then I suspect this mechanisms is too broken to publish.

Neither I understand why the "MUST use TLS" should be dropped for MSRP
over WebSocket. I cannot figure out any reasons for getting rid of
that requirement. If it was valid and appropriate for MSRP over TCP
then it should also be for MSRP over WebSocket.

Just my opinion.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 29 Jan 2014 11:12:27 -0600

> then it should also be for MSRP over WebSocket.

The argument (I'm just relaying it, not making it) has been that Websocket implementations do not give the application that level of control over the security aspects of a connection. One could counter-argue that this means those implementations are not appropriate for MSRP (I'm on the fence on that one.)

Can the authors elaborate on the implementation issues? For example, do WebSocket implementations properly handle things like HTTPS URLs?

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 29 Jan 2014 17:16:14 +0000

On Jan 29, 2014, at 10:12 AM, Ben Campbell <[email-masked]> wrote:

> he argument (I'm just relaying it, not making it) has been that Websocket implementations do not give the application that level of control over the security aspects of a connection. 

color me skeptical ….

---

From: Peter Dunkley <[email-masked]>
Date: Wed, 29 Jan 2014 12:16:48 -0500

We can put back the MUST if you want, but from a client point-of-view it
doesn't seem to make sense as choosing between TLS and not TLS is just a
matter of what WebSocket URI is used in the browser.  Further, unless you
have a trusted CA signed certificate on the server a browser won't allow
the connection - there is no UI to let you accept an exception like you
have with a web-page.

Even if TLS is left as MUST all of the additional checks from the RFC
cannot be enforced on the client because (in a browser) you don't have any
access to that information.

My reason for loosening the MUST to a SHOULD was that, pragmatically, the
security level in the MSRP Relay RFC is not achievable here.  Also, if you
are deploying MSRP internally (and did not require encryption) the
certificate handling in a browser (requiring the organisation to pay for a
certificate or importing something into each browser) is not something that
(realistically) people will do.

So by all means let's put MUST back if you want it there - but (should
anyone actually use this on a private network) that MUST will probably just
be ignored anyway.  Which makes me think SHOULD probably matches how things
will actually be used anyway.

Regards,

Peter

On 29 January 2014 11:42, Iñaki Baz Castillo <[email-masked]> wrote:

> > I don't see why using websockets would require us to get rid of the MUST
> use TLS.
> >
> > The security of relays is a total disaster if you don't have this so if
> the MUST be security authenticated goes away for relays, then I suspect
> this mechanisms is too broken to publish.
>
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 29 Jan 2014 18:22:19 +0100

> Can the authors elaborate on the implementation issues? For example, do WebSocket implementations properly handle things like HTTPS URLs?

Hi, let me please tell something about WebSocket and TLS (so URIs with
scheme "wss://"):

1) Firefox and latest version of Chrome do NOT allow insecure
(non-TLS) WebSocket connections if the web page has "https" schema.

2) When the web page is "https", Firefox and Chrome do NOT allow
WebSocket secure connections ("wss") if the WebSocket server
certificate is not valid (expired, auto-signed...). I mean: the
browser does not even prompt for permissions to the user, it just
fails the WSS connection.

Point 1) is terribly important IMHO. Note that for WebRTC applications
to be "friendly" HTTPS is required (so the user is not prompted by the
browser for permission every time a WebRTC session is requested via
getUserMedia). So let's assume that WebRTC, in fact, requires HTTPS.
Taking into account point 1) above, we also need Secure WebSocket
("wss") for MSRP or for anything.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Peter Dunkley <[email-masked]>
Date: Wed, 29 Jan 2014 12:30:37 -0500

> ("wss") for MSRP or for anything.
Which is great on the Internet but a real pain on an internal network where
you don't want to pay for a certificate or import something into every
single device/computer on your network.  That's the same reason people
usually don't use HTTPS on internal networks!

Hence my belief that SHOULD was the right thing here.  People SHOULD use
TLS security, but saying MUST will just mean that this is a MUST people
ignore on certain deployment types.  What is the point of mandating
something when people will just ignore it when it doesn't suit them?

I get that security is important and the IETF is full of security
idealists, and all IETF protocols should be secure, by in this particular
situation it feels like using MUST instead of SHOULD would be done simply
because in the IETF you always say MUST for security (whether people will
use it or not).

Regards,

Peter

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: Mary Barnes <[email-masked]>
Date: Wed, 29 Jan 2014 11:45:22 -0600

Peter et al,

This thread of discussion gets back to one of the points I made in my
shepherd review of the document (note that I don't think there's been any
responses from the authors on any of my comments):
http://www.ietf.org/mail-archive/web/dispatch/current/msg05173.html

If TLS is a SHOULD then you need to clearly explain the context in which
one might not use TLS and what the implications and risks are.  There are
still security risks (e.g., malicious actors) in internal networks.

Regards,
Mary.

On Wed, Jan 29, 2014 at 11:30 AM, Peter Dunkley <
[email-masked]> wrote:

> Which is great on the Internet but a real pain on an internal network
> where you don't want to pay for a certificate or import something into
> every single device/computer on your network.  That's the same reason
> people usually don't use HTTPS on internal networks!
>

> because in the IETF you always say MUST for security (whether people will
[MB] That's not true. But, what is true is that anytime you have a SHOULD
do x, you need to explain the situations in which you wouldn't do x and any
implications and risks associated with not doing x.  [/MB]

---

From: Peter Dunkley <[email-masked]>
Date: Wed, 29 Jan 2014 12:48:18 -0500

Hello Mary,

The document authors have been discussing updates to the documents and plan
to do work on this in the first half of February.  No-one has had time to
properly respond to the comments yet due to other commitments.

Regards,

Peter

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: Mary Barnes <[email-masked]>
Date: Wed, 29 Jan 2014 11:59:51 -0600

Peter,

Thanks for the update.

Mary.

On Wed, Jan 29, 2014 at 11:48 AM, Peter Dunkley <
[email-masked]> wrote:

> Hello Mary,
>
> The document authors have been discussing updates to the documents and
> plan to do work on this in the first half of February.  No-one has had time
> to properly respond to the comments yet due to other commitments.
>
> Regards,
>
> Peter
>
>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 29 Jan 2014 18:11:02 +0000

On Jan 29, 2014, at 10:16 AM, Peter Dunkley <[email-masked]> wrote:

> Even if TLS is left as MUST all of the additional checks from the RFC cannot be enforced on the client because (in a browser) you don't have any access to that information.

So help educate me on what is missing and lets go get that fixed in web sockets.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 29 Jan 2014 12:16:53 -0600

On Jan 29, 2014, at 11:30 AM, Peter Dunkley <[email-masked]> wrote:

> Which is great on the Internet but a real pain on an internal network where you don't want to pay for a certificate or import something into every single device/computer on your network.  That's the same reason people usually don't use HTTPS on internal networks!

I assumed MSRP/WebSocket was intended for the Internet. If not, perhaps an applicability statement would be in order, even if just for this particular requirement--although I tend to be skeptical of or "MUST use unless you are on a private network" constructs. But I can see situations where, for example, you've got protection at a lower layer (e.g. IPSec, VPNs, etc.) where it might make sense.

(BTW, more and more enterprise networks are moving to use HTTPS internally.)

> 
> Hence my belief that SHOULD was the right thing here.  People SHOULD use TLS security, but saying MUST will just mean that this is a MUST people ignore on certain deployment types.  What is the point of mandating something when people will just ignore it when it doesn't suit them?
> 
> I get that security is important and the IETF is full of security idealists, and all IETF protocols should be secure, by in this particular situation it feels like using MUST instead of SHOULD would be done simply because in the IETF you always say MUST for security (whether people will use it or not).

Actually, not so many IETF protocols say "MUST use". "MUST implement" is more common. But MSRP was an attempt to move to a more secure model, so the authors are going to be sensitive to anything that reduces that. And I suspect you will see more "MUST use" requirements these days than you might have this time last year.

Again, I think we should consider a wider policy on how to apply application protocol security requirements when the application moves to WebSocket. MSRP is an interesting test case due to the "MUST use" requirement.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 29 Jan 2014 19:17:40 +0100

> So help educate me on what is missing and lets go get that fixed in web sockets.

The browser inspects the certificate retrieved from the WS server in
the same way than when the browser connects to a HTTPS site. And the
certificate inspection means matching the server domain with the CN or
SubjectAltNames fields (DNS entries) and others usual checks.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 29 Jan 2014 18:29:31 +0000

> SubjectAltNames fields (DNS entries) and others usual checks.

Right - that sounds good - so what is missing ?

---

From: Peter Dunkley <[email-masked]>
Date: Wed, 29 Jan 2014 14:18:25 -0500

It's really just that using self-signed certificates in a browser is a real
pain.

If you have a good signed certificate it all works out.  On an internal
system many organisations don't buy certificates for internal use, people
are used to making exceptions, seeing warnings, etc.  But right now today
if your certificate is self signed and you haven't imported the right stuff
into each device that might try and make the secure WebSocket connection,
the certificate validation will fail and the connection won't be made.

I do get the argument that people and organisations SHOULD be more secure.
 Telling them they MUST be more secure tends not to work.  I am happy to
change the document to say MUST, but it comes back to the point that doing
this would be because MUST is what we put in these documents rather than
expecting people to actually do that in all situations.

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 29 Jan 2014 19:24:29 +0000

Sure I understand. But understand that MSRP has a really bad downgrade attack if you allow self signed certs. So if you want to change MSRP so it is can self signed certs for the relay, then I suggest writing a draft to do mate that change to MSRP that is separate from the Websockets draft because this is an orthogonal issue to the web sockets. 

For people that don’t want to have to get a signed certificate, I’d suggest trying to look at how to design the system to not need MSRP relays. There is a long list of ways in which MSRP relays are a huge PITA. I wish we had never added them and instead had just used TURN, or SOCKS. 

On Jan 29, 2014, at 12:18 PM, Peter Dunkley <[email-masked]> wrote:

> It's really just that using self-signed certificates in a browser is a real pain.
> 
> If you have a good signed certificate it all works out.  On an internal system many organisations don't buy certificates for internal use, people are used to making exceptions, seeing warnings, etc.  But right now today if your certificate is self signed and you haven't imported the right stuff into each device that might try and make the secure WebSocket connection, the certificate validation will fail and the connection won't be made.
> 
> I do get the argument that people and organisations SHOULD be more secure.  Telling them they MUST be more secure tends not to work.  I am happy to change the document to say MUST, but it comes back to the point that doing this would be because MUST is what we put in these documents rather than expecting people to actually do that in all situations.
> 
> 
> 
>

---

From: Peter Dunkley <[email-masked]>
Date: Wed, 29 Jan 2014 14:28:12 -0500

The intention here was to downgrade the security requirement for just MSRP
over WebSockets (still leaving it as a SHOULD) and not to change the
requirements for the existing MSRP relay specification.

Regards,

Peter

On 29 January 2014 14:24, Cullen Jennings (fluffy) <[email-masked]> wrote:

>
> Sure I understand. But understand that MSRP has a really bad downgrade
> attack if you allow self signed certs. So if you want to change MSRP so it
> is can self signed certs for the relay, then I suggest writing a draft to
> do mate that change to MSRP that is separate from the Websockets draft
> because this is an orthogonal issue to the web sockets.
>
> For people that don't want to have to get a signed certificate, I'd
> suggest trying to look at how to design the system to not need MSRP relays.
> There is a long list of ways in which MSRP relays are a huge PITA. I wish
> we had never added them and instead had just used TURN, or SOCKS.
>
>
> > I do get the argument that people and organisations SHOULD be more
> secure.  Telling them they MUST be more secure tends not to work.  I am
> happy to change the document to say MUST, but it comes back to the point
> that doing this would be because MUST is what we put in these documents
> rather than expecting people to actually do that in all situations.
> >
> >
> >
> >
> > >>> Even if TLS is left as MUST all of the additional checks from the
> RFC cannot be enforced on the client because (in a browser) you don't have
> any access to that information.
> > >>

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

---

From: Mary Barnes <[email-masked]>
Date: Wed, 29 Jan 2014 13:32:43 -0600

Yeah, but you'll need a really strong justification for this to get this
document through the IESG and I will have to sufficiently document that
this concern was raised during the expert and WG review.  You also need to
consider that this doc will be going through the process just after new ADs
are seated.  It is not at all unusual for new ADs to be extremely zealous
about documents that they review early in their term.  Based on my own
recent experiences, that discussion will likely take 10 fold of the time
you've spent in this discussion during that part of the process.

Mary.

On Wed, Jan 29, 2014 at 1:28 PM, Peter Dunkley <
[email-masked]> wrote:

> On 29 January 2014 14:24, Cullen Jennings (fluffy) <[email-masked]>wrote:
>
>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 29 Jan 2014 20:49:47 +0000

And it is not clear to me, aside from the possibility that you want to use one and not the other, why the downgrade is websocket specific.

regards

Keith

________________________________
From: dispatch [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: 29 January 2014 19:33
To: Peter Dunkley
Cc: Cullen Jennings (fluffy); [email-masked]; DISPATCH; [email-masked]; Ben Campbell
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04

Yeah, but you'll need a really strong justification for this to get this document through the IESG and I will have to sufficiently document that this concern was raised during the expert and WG review.  You also need to consider that this doc will be going through the process just after new ADs are seated.  It is not at all unusual for new ADs to be extremely zealous about documents that they review early in their term.  Based on my own recent experiences, that discussion will likely take 10 fold of the time you've spent in this discussion during that part of the process.

Mary.

On Wed, Jan 29, 2014 at 1:28 PM, Peter Dunkley <[email-masked]<mailto:[email-masked]>> wrote:
The intention here was to downgrade the security requirement for just MSRP over WebSockets (still leaving it as a SHOULD) and not to change the requirements for the existing MSRP relay specification.

Regards,

Peter

On 29 January 2014 14:24, Cullen Jennings (fluffy) <[email-masked]<mailto:[email-masked]>> wrote:

For people that don't want to have to get a signed certificate, I'd suggest trying to look at how to design the system to not need MSRP relays. There is a long list of ways in which MSRP relays are a huge PITA. I wish we had never added them and instead had just used TURN, or SOCKS.

On Jan 29, 2014, at 12:18 PM, Peter Dunkley <[email-masked]<mailto:[email-masked]>> wrote:

> On 29 January 2014 13:29, Cullen Jennings (fluffy) <[email-masked]<mailto:[email-masked]>> wrote:
>
> On Jan 29, 2014, at 11:17 AM, Iñaki Baz Castillo <[email-masked]<mailto:[email-masked]>> wrote:
>
> > 2014-01-29 Cullen Jennings (fluffy) <[email-masked]<mailto:[email-masked]>>:
> >> On Jan 29, 2014, at 10:16 AM, Peter Dunkley <[email-masked]<mailto:[email-masked]>> wrote:
> >>
> [email-masked]<mailto:[email-masked]>

--
Peter Dunkley
Technical Director
Crocodile RCS Ltd

_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 30 Jan 2014 08:33:09 +0100

I remember from SIPit WebRTC tests that we had a discussion about error codes. I wanted to set up a TLS
test on the WebSocket server but participants claimed that Javascript did not have error codes to properly
handle situations like expired cert, unrecognized CA etc etc.

I don't know if that's still the situation, but if it is, we need better tools in the browser to handle the
web socket connection.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 30 Jan 2014 10:26:11 +0100

> So help educate me on what is missing and lets go get that fixed in web sockets. 

THis is interesting. If I parse the W3C WebSocket API specification correctly, the script is not allowed to know WHY a Websocket connection failed. It's just a big failure. I would like to understand why they made this choice.

I wonder if this mixes TLS authentication with TLS encryption. We are not allowed to set up an encrypted WS connection to a self-signed cert or in general a server with a cert signed by an unknown CA even if we want to.

I just did a quick check - someone else may know ways around this. (I hope).

/O

----
User agents must not convey any failure information to scripts in a way that would allow a script to distinguish the following situations:

	• A server whose host name could not be resolved.
	• A server to which packets could not successfully be routed.
	• A server that refused the connection on the specified port.
	• A server that failed to correctly perform a TLS handshake (e.g., the server certificate can't be verified).
	• A server that did not complete the opening handshake (e.g. because it was not a WebSocket server).
	• A WebSocket server that sent a correct opening handshake, but that specified options that caused the client to drop the connection (e.g. the server specified a subprotocol that the client did not offer).
	• A WebSocket server that abruptly closed the connection after successfully completing the opening handshake.
In all of these cases, the the WebSocket connection close code would be 1006, as required by the WebSocket Protocol specification. [WSP]

Allowing a script to distinguish these cases would allow a script to probe the user's local network in preparation for an attack.
-----

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 30 Jan 2014 13:46:21 +0000

Yep, all of that with web sockets is as you say. The JS can’t figure out why the connection is not secure. All it can figure out is that it is not secure. I’m not supporting or arguing against that being a good thing but the prevalent feeling is that asking the user to make a decisions that they can’t possibly know the answer to is not secure.

Which brings us back to the key point here. As far as I can tell Websockets current API is *perfect* to implement MSRP.   

Now what some people would like to do is change MSRP so that it can run in an encrypted but not authenticated mode. This was argued at the time that MSRP was done and for a bunch of reasons it was a rally bad idea. It’s much worse than you might think. I don’t really care to redo theses arguments and I am not even going to bother to try and explain them because I mostly don’t think it will make much difference. However, if people want to change MSRP to be have this, they need to change MSRP, once that is done, then we have the problem that the Websockets API does not support this. 

But in the meantime, AFAIC, web sockets does what MSRP needs. You just need to change this draft so it is not changing the basic MSRP protocol and it will be all happy. 

But wait, I hear the howling in the background of I have no idea what it takes to practically deploy things and it is impossible to get certificates. Yah, I get it. What most people are doing that want to use self signed certs for things like this is they are installing their cert in the root trust list of the client.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 30 Jan 2014 15:25:11 +0100

2014-01-30 Olle E. Johansson <[email-masked]>:
> If I parse the W3C WebSocket API specification correctly, the script is not allowed to know WHY a Websocket connection failed. It's just a big failure. I would like to understand why they made this choice.

When RFC 6455 (Websocket) was being written I asked for the WebSocket
API [*] to provide more information about the WS connection failure
(specifically a way to know the HTTP error code if the Websocket
handshake fails due to a non HTTP 101 response). No success at all.
The rationale I was provided with is that JavaScript must not be HTTP
or TLS aware. Instead, the browser manages all these rules and errors.
Let's say that JavaScript just can play once the DNS/TCP/TLS/HTTP/WS
layers have succeeded. If they don't, JavaScript cannot figure why; it
just knows that "the connection has failed".

Believe me, that won't change.

[*] http://dev.w3.org/html5/websockets/

-- 
Iñaki Baz Castillo
<[email-masked]>