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

Peter Dunkley <peter.dunkley@crocodilertc.net> Wed, 29 January 2014 17:48 UTC

Return-Path: <peter.dunkley@crocodilertc.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 58B1C1A0352 for <dispatch@ietfa.amsl.com>; Wed, 29 Jan 2014 09:48:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 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, SPF_PASS=-0.001] 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 IWW1HTantO7o for <dispatch@ietfa.amsl.com>; Wed, 29 Jan 2014 09:48:22 -0800 (PST)
Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6A11A0276 for <dispatch@ietf.org>; Wed, 29 Jan 2014 09:48:21 -0800 (PST)
Received: by mail-ve0-f182.google.com with SMTP id jy13so1401317veb.41 for <dispatch@ietf.org>; Wed, 29 Jan 2014 09:48:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZjQ618CcszHWNOsmW5hngKkISmg5B7JCepWuG7vrcu8=; b=PEs7UbCexarp7ByCKw6kx8RH6If+9Y8kxwaVBAQhUC6ZerEQZmJ5xdavO9OQsW5rc8 WdrwEc4dLPuDqCUxbDqBjGn1hTOXYpcUnI+GNZ1wiDzKI+802KtFj8LVSIcazKrFoB7h SycOQy8YSboGNBHOw7xV4RA5HYTKkYHDjxl28=
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:date :message-id:subject:from:to:cc:content-type; bh=ZjQ618CcszHWNOsmW5hngKkISmg5B7JCepWuG7vrcu8=; b=Ys0tEV9mJilomuCDR4VR76PLd9jV3eixUkfMAB+km1roLHdUI1XEkxzRszYuKpa8gi yKpxFWkYy/xPNmoXfoYOyfPijcLQRIFCrr1IilxfaYHuKsXe9sHtY8mDw6h/QOaWyX3H XPwJOq63z9IvUKYjuwcHXvybjkuGeLWm4CBjJ9pNOt4mZz+tKN8Rl138Dsd5i5YvfRHz /f+eDeS2S2pSkXkhgpwFXM25Bq+6LFvFAigfWsthxYZecxfgXXQtLRfczyuhv0N98FFy NpQY/yI4X+zZcGzlkesr+rPTQ1GrYR1Z59Tut4C+PCXKGebR+6H0ssOL2Bs3TGuSCkEi Px2Q==
X-Gm-Message-State: ALoCoQm78Uu5I/MUrPxZvon0wFVDh82p6S1TlZqoc/xGJZ3arRs/RTvblSkvCQq/N+5pcibrvt51
MIME-Version: 1.0
X-Received: by 10.220.103.141 with SMTP id k13mr2100328vco.25.1391017698926; Wed, 29 Jan 2014 09:48:18 -0800 (PST)
Received: by 10.58.187.114 with HTTP; Wed, 29 Jan 2014 09:48:18 -0800 (PST)
In-Reply-To: <CAHBDyN6E_GJJ80ay-pat1Kc7Y+Dez3MGf2tPfhq-SWF7Hnw_Eg@mail.gmail.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> <CAHBDyN6E_GJJ80ay-pat1Kc7Y+Dez3MGf2tPfhq-SWF7Hnw_Eg@mail.gmail.com>
Date: Wed, 29 Jan 2014 12:48:18 -0500
Message-ID: <CAEqTk6TrdghHL8mZ8bQn+4e9fhdrg3k8aP1u1p=XJwts5jz8pg@mail.gmail.com>
From: Peter Dunkley <peter.dunkley@crocodilertc.net>
To: Mary Barnes <mary.ietf.barnes@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b342d30d2355204f11f8b0a
Cc: Cullen Jennings <fluffy@cisco.com>, DISPATCH <dispatch@ietf.org>, "rai@ietf.org" <rai@ietf.org>, Ben Campbell <ben@nostrum.com>, "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 17:48:24 -0000

Hello Mary,

The document authors have been discussing updates to the documents and plan
to do work on this in the first half of February.  No-one has had time to
properly respond to the comments yet due to other commitments.

Regards,

Peter


On 29 January 2014 12:45, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

> 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):
> http://www.ietf.org/mail-archive/web/dispatch/current/msg05173.html
>
> 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.
>
> Regards,
> Mary.
>
>
> On Wed, Jan 29, 2014 at 11:30 AM, Peter Dunkley <
> peter.dunkley@crocodilertc.net> wrote:
>
>>
>> On 29 January 2014 12:22, Iñaki Baz Castillo <ibc@aliax.net> 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
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>>
>


-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd