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

Iñaki Baz Castillo <ibc@aliax.net> Wed, 29 January 2014 17:22 UTC

Return-Path: <ibc@aliax.net>
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 384991A02C0 for <dispatch@ietfa.amsl.com>; Wed, 29 Jan 2014 09:22:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level:
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 KUv8hzbRxYGH for <dispatch@ietfa.amsl.com>; Wed, 29 Jan 2014 09:22:43 -0800 (PST)
Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 25EC31A0220 for <dispatch@ietf.org>; Wed, 29 Jan 2014 09:22:43 -0800 (PST)
Received: by mail-qc0-f179.google.com with SMTP id e16so3173874qcx.24 for <dispatch@ietf.org>; Wed, 29 Jan 2014 09:22:40 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Hgo32VTwnAIQhQrVFHsYa1iEumfVzx9twbr8VAhlCPA=; b=Q1szgQey7It742wtlqBGse/qCKFWH6VyNNGQOmaicT4fDNA8qoGlSz3+tBihvCVHX1 qDSlHCPB5Jz7T9x3rlhd3RIiz+2K3/dBacyZcvJrp9MThqeOhBeHG27Ztjqyuj28L7Q4 vDzqvtRQbPai9NU3qR+hmxdvtH0OVFTkTy3kEghkdMHa0RVwQLUew03o/z4JdXrwm7bf AKkcPebezeOFxcZQUPA6e4Vau++irJ23UkTbtXHZ57e4DeGbBkwU/yFsYU0q/fASiNK1 Snr3WdvON1TxVYaVgVwSyxS3czPnKeYRgXDqSLr9u8Oi2dZ1/uQGuqTch438UdofqRK7 l/fg==
X-Gm-Message-State: ALoCoQl6LkaZ/vvxN1ok2vTN0jTW5oI/e/6x7PESu3aEN9pmONOzi3yHpDmiS71sqwA7Fl1Y6lLI
X-Received: by 10.224.156.68 with SMTP id v4mr14148531qaw.66.1391016160031; Wed, 29 Jan 2014 09:22:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.96.101.232 with HTTP; Wed, 29 Jan 2014 09:22:19 -0800 (PST)
In-Reply-To: <009E92F4-DCA2-40A4-8E7A-EF6EB1BB8C06@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>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Wed, 29 Jan 2014 18:22:19 +0100
Message-ID: <CALiegf=pjkC0zLdip7pq03_jv_cLwohOKqbvO38+TVugznLL9Q@mail.gmail.com>
To: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Cullen Jennings <fluffy@cisco.com>, "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" <draft-pd-dispatch-msrp-websocket.all@tools.ietf.org>, DISPATCH <dispatch@ietf.org>, "rai@ietf.org" <rai@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 17:22:44 -0000

2014-01-29 Ben Campbell <ben@nostrum.com>:
> 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?

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
<ibc@aliax.net>