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

Mary Barnes <mary.ietf.barnes@gmail.com> Wed, 29 January 2014 19:32 UTC

Return-Path: <mary.ietf.barnes@gmail.com>
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 5182E1A03F0; Wed, 29 Jan 2014 11:32:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 didev8hmZnzx; Wed, 29 Jan 2014 11:32:46 -0800 (PST)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA161A0361; Wed, 29 Jan 2014 11:32:46 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id tp5so2534876ieb.19 for <multiple recipients>; Wed, 29 Jan 2014 11:32:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YZPw+k8+HVYXeER9BbXCVM3yAs+JNPnrbEThAe8nBwY=; b=Pd+MLTGfxHyhUSypL3CWXQfTUq9nIbhYWGfnBc72lPZoWHuo+LRMGaMcLsaSKJdQi8 Ve70yoQ74Ki+1xMzYDJ3YQiHoW5odpH0Cxm/Jyk+Z9pUjFLR4AzR9gMUZ3t18vJfMURO uRzLfpjERqG5BbKJID4dmdYcpHz+GDSAWOFkEOgkJBdESO+vFRj6W7j7VGnMUcFPgfrr 5p6U/OYswHPll2JD0XqL4BCT5c/DNS0MUQKCWVYbnW09smkXTyvFyKWTPGzllt6ACuXt pMM4NVFI/wGF5AAKXzlYhNlc2IYvlvXgcPbTaO0oPrfx0OWSF9G2vLjCEhEiro3cjvVy Ey4Q==
MIME-Version: 1.0
X-Received: by 10.50.110.3 with SMTP id hw3mr20070745igb.12.1391023963309; Wed, 29 Jan 2014 11:32:43 -0800 (PST)
Received: by 10.43.58.137 with HTTP; Wed, 29 Jan 2014 11:32:43 -0800 (PST)
In-Reply-To: <CAEqTk6QCiaS3b-qQ8W+HwLm02kYNGF77ZT=gCYDE6dFsxTUi8Q@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> <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>
Date: Wed, 29 Jan 2014 13:32:43 -0600
Message-ID: <CAHBDyN7VBje_wmxGZYJoayr10b86hNsSZ=q_FBzCRqnCLqtsFw@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Peter Dunkley <peter.dunkley@crocodilertc.net>
Content-Type: multipart/alternative; boundary=089e013cbd50350f9804f12101a4
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: [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:32:51 -0000

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> 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>wrote;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
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
>