Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]

[Alan Johnston <[e-mail]>]

Here's my thinking on this.  We have CapNeg because the default
profile for VoIP and video is unfortunately insecure RTP.  We also
need to have a single pass offer/answer negotiation since this is what
we are used to having.

While I am not in favor of allowing insecure RTP in browsers, I know
some feel this is a requirement.  I do like Chris's suggestion that
SRTP be the default, with no chrome messages trying to indicate the
security of the call, but that if RTP is used, we are universally
agreed that is is very insecure and the browser chrome should make it
very, very clear to the user that their privacy is being disregarded
by the service.

If we make SRTP the default, and allow RTP, we could do the same in
our signaling negotiation.  The default will be SRTP - this can be
expressed in SDP without CapNeg.  Should the RTCWEB clients choose to
instead negotiate RTP, then this could be done with a second SDP
Offer/Answer exchange.  This would provide yet another incentive for
services to use the secure mode.

A signaling gateway could support CapNeg and handle using 3PCC the
AVP/SAVP negotiation outside of RTCWEB.

Otherwise, if we require CapNeg in the browser, this is a large leap
in complexity, and without proven interoperability and deployment of
CapNeg today, a very risky proposition.

- Alan -

On Fri, Sep 9, 2011 at 11:31 AM, Justin Uberti <[e-mail]> wrote:
> This feels like a pretty fundamental question. I thought we were getting
> pretty close to a consensus for the signaling mechanism with Cullen's
> presentation, but this seems to complicate that significantly.
>
> On Thu, Sep 8, 2011 at 8:21 AM, Jonathan Lennox <[e-mail]> wrote:
>>
>> Indeed.
>>
>> More generally, the question is: should it be possible to send an offer
>> that by default does DTLS/SAVPF for RTCWeb, but also can fall back to other
>> RTP profiles to support legacy devices?
>>
>> If yes, then either browsers need to support CapNeg, or RTCWeb needs to
>> use something other than SDP Offer/Answer.
>>
>> If no, then supporting interop, without a media gateway, with other
>> non-RTCWeb modes (e.g., no ICE, no rtcp mux, no audio/video mux, etc.)
>> becomes IMO a lot less compelling.
>>
>> -----Original Message-----
>> From: Christer Holmberg [mailto:[e-mail]]
>> Sent: Thursday, September 08, 2011 2:35 AM
>> To: Randell Jesup; Jonathan Lennox
>> Cc: [e-mail]
>> Subject: AVPF [was: [rtcweb] Encryption mandate (and offer/answer)]
>>
>>
>> Hi,
>>
>> >>>You could make forced-encryption the default, and allow the
>> >>>application control over whether to allow it is turned off for
>> >>>specific cases, like a PSTN call, or under the server's control.
>> >>>Signalling is secure, so it could even use a direct optional
>> >>>downgrade from SAVP* to AVP* (i.e.
>> >>>similar to the best-effort-strp draft)
>> >>This has implications for the parallel thread about the use of SDP
>> >>offer/answer.
>> >>
>> >>The solution MMUSIC has standardized for best-effort SRTP is SDP
>> >>CapNeg, RFC 5939.  Do we want to require CapNeg support in browsers?
>> >
>> >Yeah, ok, I'm not going there.  :-)  It's probably not needed for this
>> >use-case anyways.
>>
>> The same question exists for AVPF, which has been suggested to be
>> mandated.
>>
>> Regards,
>>
>> Christer
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>