Re: [RAI] [dispatch] 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> 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:
>
>>
>> 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>:
>> > >> 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
>
>