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

"Olle E. Johansson" <oej@edvina.net> Thu, 30 January 2014 07:33 UTC

Return-Path: <oej@edvina.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 E10C31A04F8; Wed, 29 Jan 2014 23:33:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 pRG0YED99Bq1; Wed, 29 Jan 2014 23:33:15 -0800 (PST)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 68BF61A0476; Wed, 29 Jan 2014 23:33:13 -0800 (PST)
Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 7F69D93C2A2; Thu, 30 Jan 2014 07:33:09 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7F30C153-A42D-4DD8-A287-6187A6EE9F98"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <CAEqTk6RzkDVZaeOvAkD4JfLG_HGEYp+CXH6Nm7hMdSoLoyGLFg@mail.gmail.com>
Date: Thu, 30 Jan 2014 08:33:09 +0100
Message-Id: <3DE18DC8-CC7D-43A1-BB49-8EA154528391@edvina.net>
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> <CAEqTk6Q2Dv4a2P-8KJtK=xGZx=mmayt_YdagF2=JyoJ1oYQu7w@mail.gmail.com> <1E320318-64CE-4F8B-AB76-8C4A5244379A@cisco.com> <CALiegfmWXmOYu2gQj8b6=JgC2CfZoFJqebM=E6OrJ6j-QwLepg@mail.gmail.com> <8DB45325-9CCA-411C-A809-9B716616CE2F@cisco.com> <CAEqTk6RzkDVZaeOvAkD4JfLG_HGEYp+CXH6Nm7hMdSoLoyGLFg@mail.gmail.com>
To: Peter Dunkley <peter.dunkley@crocodilertc.net>
X-Mailer: Apple Mail (2.1827)
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Ben Campbell <ben@nostrum.com>, DISPATCH <dispatch@ietf.org>, "rai@ietf.org" <rai@ietf.org>, "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: Thu, 30 Jan 2014 07:33:18 -0000

I remember from SIPit WebRTC tests that we had a discussion about error codes. I wanted to set up a TLS
test on the WebSocket server but participants claimed that Javascript did not have error codes to properly
handle situations like expired cert, unrecognized CA etc etc.

I don't know if that's still the situation, but if it is, we need better tools in the browser to handle the
web socket connection.

/O

On 29 Jan 2014, at 20:18, Peter Dunkley <peter.dunkley@crocodilertc.net> wrote:

> It's really just that using self-signed certificates in a browser is a real pain.
> 
> If you have a good signed certificate it all works out.  On an internal system many organisations don't buy certificates for internal use, people are used to making exceptions, seeing warnings, etc.  But right now today if your certificate is self signed and you haven't imported the right stuff into each device that might try and make the secure WebSocket connection, the certificate validation will fail and the connection won't be made.
> 
> I do get the argument that people and organisations SHOULD be more secure.  Telling them they MUST be more secure tends not to work.  I am happy to change the document to say MUST, but it comes back to the point that doing this would be because MUST is what we put in these documents rather than expecting people to actually do that in all situations.
> 
> 
> 
> 
> On 29 January 2014 13:29, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
> 
> On Jan 29, 2014, at 11:17 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
> 
> > 2014-01-29 Cullen Jennings (fluffy) <fluffy@cisco.com>:
> >> On Jan 29, 2014, at 10:16 AM, Peter Dunkley <peter.dunkley@crocodilertc.net> wrote:
> >>
> >>> 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.
> >>
> >> So help educate me on what is missing and lets go get that fixed in web sockets.
> >
> >
> > The browser inspects the certificate retrieved from the WS server in
> > the same way than when the browser connects to a HTTPS site. And the
> > certificate inspection means matching the server domain with the CN or
> > SubjectAltNames fields (DNS entries) and others usual checks.
> 
> 
> Right - that sounds good - so what is missing ?
> 
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 
> 
> 
> -- 
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch