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

Peter Dunkley <> Wed, 29 January 2014 17:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 95E081A0276 for <>; Wed, 29 Jan 2014 09:30:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.078
X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ePrunXX4tA9r for <>; Wed, 29 Jan 2014 09:30:41 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c01::235]) by (Postfix) with ESMTP id 0C9FE1A0216 for <>; Wed, 29 Jan 2014 09:30:40 -0800 (PST)
Received: by with SMTP id cz12so1382421veb.26 for <>; Wed, 29 Jan 2014 09:30:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TTBY8u9Tfcgq7RyepmJonohHpiLWMBzR9AncUfJMpTs=; b=KD4q+jXO70EZYYqNTZD4E3WKeSBZBq6ja3M+p7MU0WPOY9d/bfQwsbqsM0yABuO41u Zpm9ypmTUPVQIl01Mp9lXzFZPS9Hjl6dyzl+vG1+WbRVmq9W2n6fjzO3SBRyVqlgSBP7 Cguc/fRNpOlflLSfomgCdJ6UrN85tNAY8Kon8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TTBY8u9Tfcgq7RyepmJonohHpiLWMBzR9AncUfJMpTs=; b=Th/Ht+m5oEWTLjYkGV4CfSTktIor0JRYGss9G+tlKtrI0OS+iBpqOYubj67daDWXe/ 9Tvz1mfzn4Z2/e6iZ8v1hRrHHV6FRDGAZLOFjjnAP8Sdnhlazw/rezJcqffI4zc+PwFg nOXILTn3z5gqgpQ2fgvK9i85tFddAfQXMSCFYFWkShOzSbWvNCjDrptFM/3pA+In6RW7 Ekar/mek1IYbWthse65PkXoSu38mvIZctgQoCvy82Ed/K+jR77DtFUHya7M+QDD9Qwsm p9fEBtZx0tZEqR/zBNlv9bOuiIJXJff/C/xHM7UE+Cw2rfNkl4BtvXFhfXun7y2UGMhm DN4A==
X-Gm-Message-State: ALoCoQmX1mzRaOCm3JTgCsc0luMLvPnp62jOXilNUj9CzUmNEmFDErkc/y82Vo8qhqRz3pelsn23
MIME-Version: 1.0
X-Received: by with SMTP id bs1mr1657926veb.29.1391016637919; Wed, 29 Jan 2014 09:30:37 -0800 (PST)
Received: by with HTTP; Wed, 29 Jan 2014 09:30:37 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Wed, 29 Jan 2014 12:30:37 -0500
Message-ID: <>
From: Peter Dunkley <>
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <>
Content-Type: multipart/alternative; boundary=089e0118457494999a04f11f4cc4
Cc: Cullen Jennings <>, Ben Campbell <>, DISPATCH <>, "" <>, "" <>
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Jan 2014 17:30:42 -0000

On 29 January 2014 12:22, Iñaki Baz Castillo <> 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).



Peter Dunkley
Technical Director
Crocodile RCS Ltd