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

Mary Barnes <mary.ietf.barnes@gmail.com> Wed, 29 January 2014 17:59 UTC

Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: rai@ietfa.amsl.com
Delivered-To: rai@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6557D1A0216; Wed, 29 Jan 2014 09:59:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaV9VDFRgVdU; Wed, 29 Jan 2014 09:59:54 -0800 (PST)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 96CD41A0146; Wed, 29 Jan 2014 09:59:54 -0800 (PST)
Received: by mail-ig0-f182.google.com with SMTP id uy17so5159729igb.3 for <multiple recipients>; Wed, 29 Jan 2014 09:59:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W5bn1j4+NEXXvTl1Ywvu6PeUWHDrSbzd3eA63g6JaFE=; b=gd0aOClVtCI84jERPpFpZEyl0QCPGfiQRhU0zrJ3q6pGZPG7VJBRk63aGM0ddm2IGr MXCY/t8bQBgwUi+tnsYMRrZvRzGN7WIHxPqohr03I07X2lCfhgpuIdyUu+m5O2BxqP9N +TYpwj7vW+tBibRdM9gtJJ5Nxu/5+HgHzPvoNxPJpvYpwMnXaPyBCW4+EcFaRCSKzjI+ NqwLtPpeu6cbCQ9YKC7K4dIkkn5yT+0VJeSuwWe+ZP/2s13PjdN0KyKvwFXIKOJd8grM AUuKnq9zcEMwgv+ty8+nlReK0VXeHsL5tJXz2VoJfnl/W3I3AkvC6JBFo/uxDGbFbW2j nO5A==
MIME-Version: 1.0
X-Received: by 10.50.110.3 with SMTP id hw3mr19633045igb.12.1391018391590; Wed, 29 Jan 2014 09:59:51 -0800 (PST)
Received: by 10.43.58.137 with HTTP; Wed, 29 Jan 2014 09:59:51 -0800 (PST)
In-Reply-To: <CAEqTk6TrdghHL8mZ8bQn+4e9fhdrg3k8aP1u1p=XJwts5jz8pg@mail.gmail.com>
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com> <A25E55DD-59E3-4F43-BE9A-6304378FAE0B@cisco.com> <CALiegf=mn1Lg6ihhf8hamn6rVpkLnF3ydGxm1tK1JaNMaioxoQ@mail.gmail.com> <009E92F4-DCA2-40A4-8E7A-EF6EB1BB8C06@nostrum.com> <CALiegf=pjkC0zLdip7pq03_jv_cLwohOKqbvO38+TVugznLL9Q@mail.gmail.com> <CAEqTk6RxBmiu0AwskaOE4yPsiCaswj6_sXGYPYJxTuNSRjts+g@mail.gmail.com> <CAHBDyN6E_GJJ80ay-pat1Kc7Y+Dez3MGf2tPfhq-SWF7Hnw_Eg@mail.gmail.com> <CAEqTk6TrdghHL8mZ8bQn+4e9fhdrg3k8aP1u1p=XJwts5jz8pg@mail.gmail.com>
Date: Wed, 29 Jan 2014 11:59:51 -0600
Message-ID: <CAHBDyN6Nzku1gd3G_X9f9vre3Z6kZm+02PbfE9QypzGuGP+RLg@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Peter Dunkley <peter.dunkley@crocodilertc.net>
Content-Type: multipart/alternative; boundary=089e013cbd501bed2504f11fb5b3
Cc: Cullen Jennings <fluffy@cisco.com>, =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>, DISPATCH <dispatch@ietf.org>, "rai@ietf.org" <rai@ietf.org>, Ben Campbell <ben@nostrum.com>, "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" <draft-pd-dispatch-msrp-websocket.all@tools.ietf.org>
Subject: Re: [RAI] [dispatch] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rai/>
List-Post: <mailto:rai@ietf.org>
List-Help: <mailto:rai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2014 17:59:57 -0000

Peter,

Thanks for the update.

Mary.


On Wed, Jan 29, 2014 at 11:48 AM, Peter Dunkley <
peter.dunkley@crocodilertc.net>; 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
>
>
> On 29 January 2014 12:45, Mary Barnes <mary.ietf.barnes@gmail.com>; 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 <
>> peter.dunkley@crocodilertc.net>; wrote:
>>
>>>
>>> On 29 January 2014 12:22, IƱaki Baz Castillo <ibc@aliax.net>; 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
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>
>>>
>>
>
>
> --
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
>