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

Mary Barnes <> Wed, 29 January 2014 17:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DE9001A0276; Wed, 29 Jan 2014 09:45:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rb0SGLVC-y5b; Wed, 29 Jan 2014 09:45:25 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c03::234]) by (Postfix) with ESMTP id 5535C1A0146; Wed, 29 Jan 2014 09:45:25 -0800 (PST)
Received: by with SMTP id at1so2385474iec.39 for <multiple recipients>; Wed, 29 Jan 2014 09:45:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FeMXk/rWfwNrPXdfpA8jSxlaHHbfJF8Z3nptvJKl4Zk=; b=nLJRXDmEArnVE1EwMrMlwnguezMACk7e2J3h7hRLdJ4OnRUEqfSUZz4kNW+lY3YkjM dr9XK1rnyzpUcnZEpBQlf6cucsT5OLKiD8usMiLy+BLh3AcMxhVFX2Jp/tKFZOjPKoYG lKf4MMBtHaTMwrvW58B3LqBSF6zwDRJutDVnQyhIU60eDRV5f6XUi5a1lzaPMbe1A6Yi tqSsuL49vjYJzzK4l4OvlA9Zt0nHjOQ3QGgtjCVQV4YvcZQtIhUYh/EbvKpvIRFhu4xF 7pf9wWjCLXkSdCoBO9eBc/r/6d4sDJumGvgFMQS5FOrBLgVd11EO3bORDVfXnCUjL+vA rnvA==
MIME-Version: 1.0
X-Received: by with SMTP id hw3mr19566924igb.12.1391017522252; Wed, 29 Jan 2014 09:45:22 -0800 (PST)
Received: by with HTTP; Wed, 29 Jan 2014 09:45:22 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Wed, 29 Jan 2014 11:45:22 -0600
Message-ID: <>
From: Mary Barnes <>
To: Peter Dunkley <>
Content-Type: multipart/alternative; boundary=089e013cbd504a524b04f11f8108
Cc: Cullen Jennings <>, =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <>, DISPATCH <>, "" <>, Ben Campbell <>, "" <>
Subject: Re: [RAI] [dispatch] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Jan 2014 17:45:28 -0000

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):

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.


On Wed, Jan 29, 2014 at 11:30 AM, Peter Dunkley <> wrote:

> 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).
[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