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

Ben Campbell <ben@nostrum.com> Wed, 29 January 2014 18:17 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0FD1A0369; Wed, 29 Jan 2014 10:17:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level:
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 U7m32hf_igpH; Wed, 29 Jan 2014 10:17:12 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E9C291A021B; Wed, 29 Jan 2014 10:17:11 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s0TIGseM008270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Jan 2014 12:16:55 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <CAEqTk6RxBmiu0AwskaOE4yPsiCaswj6_sXGYPYJxTuNSRjts+g@mail.gmail.com>
Date: Wed, 29 Jan 2014 12:16:53 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <CDB58D98-5E43-4CA2-B3E1-F3C4EBC712C1@nostrum.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>
To: Peter Dunkley <peter.dunkley@crocodilertc.net>
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: Cullen Jennings <fluffy@cisco.com>, DISPATCH <dispatch@ietf.org>, "rai@ietf.org" <rai@ietf.org>, "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" <draft-pd-dispatch-msrp-websocket.all@tools.ietf.org>
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2014 18:17:13 -0000

On Jan 29, 2014, at 11:30 AM, Peter Dunkley <peter.dunkley@crocodilertc.net> wrote:

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

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.

>