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

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Wed, 29 January 2014 20:50 UTC

Return-Path: <keith.drage@alcatel-lucent.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 E68731A03FE; Wed, 29 Jan 2014 12:50:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] 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 ueOOTfPBeMvg; Wed, 29 Jan 2014 12:50:00 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 5030F1A027B; Wed, 29 Jan 2014 12:50:00 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s0TKnmo4016217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Jan 2014 14:49:49 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s0TKnlTN021372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jan 2014 21:49:47 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 29 Jan 2014 21:49:47 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Mary Barnes <mary.ietf.barnes@gmail.com>, Peter Dunkley <peter.dunkley@crocodilertc.net>
Thread-Topic: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
Thread-Index: AQHPHShMmG+GTMZ0DEmjyWZEeE7thZqcBq6AgAAmCsA=
Date: Wed, 29 Jan 2014 20:49:47 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B125547@FR712WXCHMBA11.zeu.alcatel-lucent.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> <CAEqTk6QCiaS3b-qQ8W+HwLm02kYNGF77ZT=gCYDE6dFsxTUi8Q@mail.gmail.com> <CAHBDyN7VBje_wmxGZYJoayr10b86hNsSZ=q_FBzCRqnCLqtsFw@mail.gmail.com>
In-Reply-To: <CAHBDyN7VBje_wmxGZYJoayr10b86hNsSZ=q_FBzCRqnCLqtsFw@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.38]
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B125547FR712WXCHMBA11zeu_"
MIME-Version: 1.0
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, "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: Wed, 29 Jan 2014 20:50:05 -0000

And it is not clear to me, aside from the possibility that you want to use one and not the other, why the downgrade is websocket specific.

regards

Keith

________________________________
From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 29 January 2014 19:33
To: Peter Dunkley
Cc: Cullen Jennings (fluffy); draft-pd-dispatch-msrp-websocket.all@tools.ietf.org; DISPATCH; rai@ietf.org; Ben Campbell
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04

Yeah, but you'll need a really strong justification for this to get this document through the IESG and I will have to sufficiently document that this concern was raised during the expert and WG review.  You also need to consider that this doc will be going through the process just after new ADs are seated.  It is not at all unusual for new ADs to be extremely zealous about documents that they review early in their term.  Based on my own recent experiences, that discussion will likely take 10 fold of the time you've spent in this discussion during that part of the process.

Mary.


On Wed, Jan 29, 2014 at 1:28 PM, Peter Dunkley <peter.dunkley@crocodilertc.net<mailto:peter.dunkley@crocodilertc.net>> wrote:
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<mailto: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<mailto: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<mailto:fluffy@cisco.com>> wrote:
>
> On Jan 29, 2014, at 11:17 AM, Iñaki Baz Castillo <ibc@aliax.net<mailto:ibc@aliax.net>> wrote:
>
> > 2014-01-29 Cullen Jennings (fluffy) <fluffy@cisco.com<mailto:fluffy@cisco.com>>:
> >> On Jan 29, 2014, at 10:16 AM, Peter Dunkley <peter.dunkley@crocodilertc.net<mailto: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<mailto:dispatch@ietf.org>
> https://www.ietf.org/mailman/listinfo/dispatch
>
>
>
> --
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd




--
Peter Dunkley
Technical Director
Crocodile RCS Ltd

_______________________________________________
dispatch mailing list
dispatch@ietf.org<mailto:dispatch@ietf.org>
https://www.ietf.org/mailman/listinfo/dispatch