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

Peter Dunkley <peter.dunkley@crocodilertc.net> Wed, 29 January 2014 19:28 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 4431C1A0361 for <dispatch@ietfa.amsl.com>; Wed, 29 Jan 2014 11:28:19 -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 OH6tigIL97bo for <dispatch@ietfa.amsl.com>; Wed, 29 Jan 2014 11:28:16 -0800 (PST)
Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 370411A03C5 for <dispatch@ietf.org>; Wed, 29 Jan 2014 11:28:16 -0800 (PST)
Received: by mail-vb0-f46.google.com with SMTP id o19so1419829vbm.5 for <dispatch@ietf.org>; Wed, 29 Jan 2014 11:28:13 -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=qXxNGsolaMuQTZdqf6LWaVCiqYWO8H4AJv3ztAGNqGQ=; b=cAjuLJKrOjEh7tMGo0KNHCxcS71XvqaOE1B0OjHZUCeSgYhO1922/uFWi5BBO6tPYy 7bTc9apHI89Ei4wZwsDq6hE1PtxK1mhrgroWtigYI4PnZT0nZJU3r57drTIPSb8uEM3O 58cs0AtqZbSEagfP0OlvIvq1X45HvN646SpSc=
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=qXxNGsolaMuQTZdqf6LWaVCiqYWO8H4AJv3ztAGNqGQ=; b=IYctWwZUup+X0zWRpEyt5Vdxg1RNppZnla9Qrw/LDRTM7ilKbrLtLjzbfftLtaoVnO IIyDf8pokrWV3SRzrviekXQax4ckkSCszsouZOxl02CZ0scxU/Q6gk2x8nsKUYCMMVDt NdpmlwvkCA7LwrJDniAsyeQ6m8waobXZmEq1oFSxCtfbDK2jhuC8FjQ3f6OG/yipLufU BPKOtVlo9SDaAyUUK7BZ0nHd+yHIWp0acTPjR0geeOFGZ4yLrg3KX799eM1OZRLM58wu ZqyYIVIuzx1tGAhaHCKYtG0ICM1mjw/dj5U0scOmRLMnaXkOkQuvGzMQOtTLBi/8ZPmh MqXg==
X-Gm-Message-State: ALoCoQliDF50wkedeDT0upVowJoB+4Yf64ORaYa6OudnswHTzfYuaWXvgR2QP6e9jhHNaiL8+7vj
MIME-Version: 1.0
X-Received: by 10.58.188.78 with SMTP id fy14mr2929177vec.23.1391023693012; Wed, 29 Jan 2014 11:28:13 -0800 (PST)
Received: by 10.58.187.114 with HTTP; Wed, 29 Jan 2014 11:28:12 -0800 (PST)
In-Reply-To: <DB0CE001-12CF-48F5-95A2-C948A17447AB@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> <CALiegfmWXmOYu2gQj8b6=JgC2CfZoFJqebM=E6OrJ6j-QwLepg@mail.gmail.com> <8DB45325-9CCA-411C-A809-9B716616CE2F@cisco.com> <CAEqTk6RzkDVZaeOvAkD4JfLG_HGEYp+CXH6Nm7hMdSoLoyGLFg@mail.gmail.com> <DB0CE001-12CF-48F5-95A2-C948A17447AB@cisco.com>
Date: Wed, 29 Jan 2014 14:28:12 -0500
Message-ID: <CAEqTk6QCiaS3b-qQ8W+HwLm02kYNGF77ZT=gCYDE6dFsxTUi8Q@mail.gmail.com>
From: Peter Dunkley <peter.dunkley@crocodilertc.net>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Content-Type: multipart/alternative; boundary=089e013a12f018c40d04f120f1fd
Cc: 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>, Ben Campbell <ben@nostrum.com>
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 19:28:19 -0000

The intention here was to downgrade the security requirement for just MSRP
over WebSockets (still leaving it as a SHOULD) and not to change the
requirements for the existing MSRP relay specification.

Regards,

Peter


On 29 January 2014 14:24, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:

>
> Sure I understand. But understand that MSRP has a really bad downgrade
> attack if you allow self signed certs. So if you want to change MSRP so it
> is can self signed certs for the relay, then I suggest writing a draft to
> do mate that change to MSRP that is separate from the Websockets draft
> because this is an orthogonal issue to the web sockets.
>
> For people that don't want to have to get a signed certificate, I'd
> suggest trying to look at how to design the system to not need MSRP relays.
> There is a long list of ways in which MSRP relays are a huge PITA. I wish
> we had never added them and instead had just used TURN, or SOCKS.
>
>
> On Jan 29, 2014, at 12:18 PM, 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>om>:
> > >> 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
>
>


-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd