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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F0A521A02DD for <>; Wed, 29 Jan 2014 09:16:53 -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 UIBdm5FHLvzs for <>; Wed, 29 Jan 2014 09:16:51 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c02::232]) by (Postfix) with ESMTP id 585991A0355 for <>; Wed, 29 Jan 2014 09:16:51 -0800 (PST)
Received: by with SMTP id w8so1306513vbj.23 for <>; Wed, 29 Jan 2014 09:16:48 -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=gFJyuor+l0+g/IziGFIo6xYFW5VigiMk6v7VRmhAZ9w=; b=fZJpvhy4X1OGcZae4Yg2jaiw3yq7743LtSWbaEmvSGcnrHcDjpd3O6p2AQPG4df5BA kJOXh3KD3mq6fXzbwcUbkKc37HJ5t5rB72BM3HlY6ngZERt2gH44dljRSzFUbH94H7mW vpQHNADtr4XceLqUju7ECP6yEdXCbCZizhD8s=
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=gFJyuor+l0+g/IziGFIo6xYFW5VigiMk6v7VRmhAZ9w=; b=L3jzaZkwkeP4TkXlrez6+cMDaDeeDDRQGwOiqdUX9p83sma0P7qf9WochynZKSWPYk HpnnUlGYu1vMrebrX53UKiWNJLGVhDs3fVU+jkm84qg5CeZVDZ02d4zNCwF0Dmpi1Rx6 FbL+vGywQI1nYsWc0tJfr8BRyYp9tvfJLj2pJSu7OtWq5nqgMp5/lRXuDg4UB2ukwxbC OVphhkFmyRGMZjL9KCfbYNl8uW1jOeJ8KquRLEHqjQMKpp8EC7bdV4IsjJ1LH5oH6xrs T+qzNODdex5SB2qV0ef+FNMp7YcN8fPfff2iP9CTjeI4V8s6b7xSNdnx1oJwHZFu/5lk lioQ==
X-Gm-Message-State: ALoCoQl9K3ahh4KqCeK/myr/mSGcj0M29iE8m2H1BOznaMdnRLc9xSb2QeRR2h7E8nHmxw0pdL96
MIME-Version: 1.0
X-Received: by with SMTP id fv8mr252813vdc.60.1391015808167; Wed, 29 Jan 2014 09:16:48 -0800 (PST)
Received: by with HTTP; Wed, 29 Jan 2014 09:16:48 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Wed, 29 Jan 2014 12:16:48 -0500
Message-ID: <>
From: Peter Dunkley <>
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <>
Content-Type: multipart/alternative; boundary=bcaec548a6031f8bbc04f11f1b6c
Cc: "Cullen Jennings \(fluffy\)" <>, 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:16:54 -0000

We can put back the MUST if you want, but from a client point-of-view it
doesn't seem to make sense as choosing between TLS and not TLS is just a
matter of what WebSocket URI is used in the browser.  Further, unless you
have a trusted CA signed certificate on the server a browser won't allow
the connection - there is no UI to let you accept an exception like you
have with a web-page.

Even if TLS is left as MUST all of the additional checks from the RFC
cannot be enforced on the client because (in a browser) you don't have any
access to that information.

My reason for loosening the MUST to a SHOULD was that, pragmatically, the
security level in the MSRP Relay RFC is not achievable here.  Also, if you
are deploying MSRP internally (and did not require encryption) the
certificate handling in a browser (requiring the organisation to pay for a
certificate or importing something into each browser) is not something that
(realistically) people will do.

So by all means let's put MUST back if you want it there - but (should
anyone actually use this on a private network) that MUST will probably just
be ignored anyway.  Which makes me think SHOULD probably matches how things
will actually be used anyway.



On 29 January 2014 11:42, Iñaki Baz Castillo <> wrote:

> 2014-01-29 Cullen Jennings (fluffy) <>om>:
> > I don't see why using websockets would require us to get rid of the MUST
> use TLS.
> >
> > The security of relays is a total disaster if you don't have this so if
> the MUST be security authenticated goes away for relays, then I suspect
> this mechanisms is too broken to publish.
> Neither I understand why the "MUST use TLS" should be dropped for MSRP
> over WebSocket. I cannot figure out any reasons for getting rid of
> that requirement. If it was valid and appropriate for MSRP over TCP
> then it should also be for MSRP over WebSocket.
> Just my opinion.
> --
> Iñaki Baz Castillo
> <>
> _______________________________________________
> dispatch mailing list

Peter Dunkley
Technical Director
Crocodile RCS Ltd