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

[Peter Dunkley <[e-mail]>]

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


On 29 January 2014 12:45, Mary Barnes <[e-mail]> wrote:

> 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 <
> [e-mail]> wrote:
>
>>
>> On 29 January 2014 12:22, Iñaki Baz Castillo <[e-mail]> wrote:
>>
>>> 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.
>>>
>>>
>> 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).
>>
> [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]
>
>>
>> Regards,
>>
>> Peter
>>
>> --
>> Peter Dunkley
>> Technical Director
>> Crocodile RCS Ltd
>>
>> _______________________________________________
>> dispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>>
>


-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd