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

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Thu, 30 January 2014 13:46 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: rai@ietfa.amsl.com
Delivered-To: rai@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3023A1A02C8; Thu, 30 Jan 2014 05:46:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.036
X-Spam-Level:
X-Spam-Status: No, score=-110.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
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 mdt10fSdVJp1; Thu, 30 Jan 2014 05:46:27 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 0787B1A026C; Thu, 30 Jan 2014 05:46:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4005; q=dns/txt; s=iport; t=1391089584; x=1392299184; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TxCNdWgi3Kz3NGJ7GzRBLNe5Hf1UnZfrqCJPp0nWk8o=; b=Ye5Z7BZbV/sR0DH8VK6ebuLxIXP5ENWHymfTIDKYUk+jBOS7SyZAePki k+86q3/GHeZPNYy58f46JyyYztE7ZU1bcmiMGMyhWmvtBO5e+qJURLsye hv6jzjfY47+nmmfhNWRKEvMEopB0f1UBnzFZHBOWPP8ndx+Sn9JJ6z9Kj U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgwFAFVX6lKtJV2d/2dsb2JhbABZgwyBD70lgQkWdIIlAQEBAwFrDhACAQgYLjIlAgQOBYd9CMt/F45PMweDJIEUBJgokh+DLYIq
X-IronPort-AV: E=Sophos;i="4.95,750,1384300800"; d="scan'208";a="16695495"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 30 Jan 2014 13:46:21 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0UDkLTN016937 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jan 2014 13:46:21 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Thu, 30 Jan 2014 07:46:21 -0600
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: Olle E Johansson <oej@edvina.net>
Thread-Topic: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
Thread-Index: AQHPHcGoC5imXzrTE0i6MBdPHXvDBQ==
Date: Thu, 30 Jan 2014 13:46:21 +0000
Message-ID: <CD225513-92E1-422E-B9F6-7B46AA910650@cisco.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> <CAEqTk6Q2Dv4a2P-8KJtK=xGZx=mmayt_YdagF2=JyoJ1oYQu7w@mail.gmail.com> <1E320318-64CE-4F8B-AB76-8C4A5244379A@cisco.com> <02B7636E-68F1-4513-B214-44635162874D@edvina.net>
In-Reply-To: <02B7636E-68F1-4513-B214-44635162874D@edvina.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <6E6F5293E20CFA43BB509C9A8D0469D5@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" <draft-pd-dispatch-msrp-websocket.all@tools.ietf.org>, DISPATCH <dispatch@ietf.org>, "rai@ietf.org" <rai@ietf.org>, Ben Campbell <ben@nostrum.com>
Subject: Re: [RAI] [dispatch] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rai/>
List-Post: <mailto:rai@ietf.org>
List-Help: <mailto:rai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2014 13:46:31 -0000

Yep, all of that with web sockets is as you say. The JS can’t figure out why the connection is not secure. All it can figure out is that it is not secure. I’m not supporting or arguing against that being a good thing but the prevalent feeling is that asking the user to make a decisions that they can’t possibly know the answer to is not secure.

Which brings us back to the key point here. As far as I can tell Websockets current API is *perfect* to implement MSRP.   

Now what some people would like to do is change MSRP so that it can run in an encrypted but not authenticated mode. This was argued at the time that MSRP was done and for a bunch of reasons it was a rally bad idea. It’s much worse than you might think. I don’t really care to redo theses arguments and I am not even going to bother to try and explain them because I mostly don’t think it will make much difference. However, if people want to change MSRP to be have this, they need to change MSRP, once that is done, then we have the problem that the Websockets API does not support this. 

But in the meantime, AFAIC, web sockets does what MSRP needs. You just need to change this draft so it is not changing the basic MSRP protocol and it will be all happy. 

But wait, I hear the howling in the background of I have no idea what it takes to practically deploy things and it is impossible to get certificates. Yah, I get it. What most people are doing that want to use self signed certs for things like this is they are installing their cert in the root trust list of the client. 



On Jan 30, 2014, at 2:26 AM, Olle E. Johansson <oej@edvina.net>; wrote:

> 
> On 29 Jan 2014, at 19:11, Cullen Jennings (fluffy) <fluffy@cisco.com>; wrote:
> 
>> 
>> 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. 
>> 
> 
> THis is interesting. If I parse the W3C WebSocket API specification correctly, the script is not allowed to know WHY a Websocket connection failed. It's just a big failure. I would like to understand why they made this choice.
> 
> I wonder if this mixes TLS authentication with TLS encryption. We are not allowed to set up an encrypted WS connection to a self-signed cert or in general a server with a cert signed by an unknown CA even if we want to.
> 
> I just did a quick check - someone else may know ways around this. (I hope).
> 
> /O
> 
> ----
> User agents must not convey any failure information to scripts in a way that would allow a script to distinguish the following situations:
> 
> 	• A server whose host name could not be resolved.
> 	• A server to which packets could not successfully be routed.
> 	• A server that refused the connection on the specified port.
> 	• A server that failed to correctly perform a TLS handshake (e.g., the server certificate can't be verified).
> 	• A server that did not complete the opening handshake (e.g. because it was not a WebSocket server).
> 	• A WebSocket server that sent a correct opening handshake, but that specified options that caused the client to drop the connection (e.g. the server specified a subprotocol that the client did not offer).
> 	• A WebSocket server that abruptly closed the connection after successfully completing the opening handshake.
> In all of these cases, the the WebSocket connection close code would be 1006, as required by the WebSocket Protocol specification. [WSP]
> 
> Allowing a script to distinguish these cases would allow a script to probe the user's local network in preparation for an attack.
> -----