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

[Justin Uberti <[e-mail]>]

On Fri, Sep 9, 2011 at 1:47 PM, Alan Johnston <[e-mail]>wrote:

> 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.
>

So would it work like this?
Assume participants A (prefers secure) and B (only supports insecure)
A -> B (offer with DTLS/SRTP)
B -> A (answer with 488 or other error)
A -> B (offer with plain old RTP)
B -> A (answer with 200)

I prefer Jingle's way of allowing crypto to be agreed upon in a single o/a
exchange, but this seems OK too.


> 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
> >
> >
>